Description of problem:
The __ISR_VALID and si_flags macros and the corresponding field of the siginfo
struct for EL3.0 are missing from /usr/include/bits/siginfo.h. We have used
these fields on previous versions of RedHat Linux to determine whether the
instruction causing a SEGV was a load or a store. Is there a new function that
we can use to get this information? Or is there another field that we can use
for this? Our code does not compile with EL3.0 RC1 - we get a "missing field"
error from the compiler.
The macros and fields ARE found in /usr/src/linux/include/asm-ia64/siginfo.h.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
This has nothing to do with the kernel but with glibc-kernheaders or glibc
Can you please expand about the "on previous versions of Red Hat Linux" claim?
<bits/siginfo.h> on IA-64 never ever had si_flags nor __ISR_VALID macros in it.
This is not to say they cannot be added, just wondering why you claim it worked
before. Similarly, si_flags nor __ISR_VALID have never been in /usr/include/asm/siginfo.h
in any RHL or RHEL version for IA-64.
We were mistaken about the previous versions claim. We have some
convoluted user-level code that reinvents the info that the kernel
already has about the instruction. We need to know whether the
instruction that caused the segv was a read or a write. Apparently
it is available through the si_flags field
We would like get access to that info through the siginfo.h available
to user code. If this was exported to users, it would speedup up our
software since we would not have to re-compute it on every faulting
access in our distributed shared memory system.
What are the chances that the si_flags field could be made accessible
Any change to si_flags would be a kernel change. Talk to the upstream
kernel developers. David Mosberger for ia64. If he implements
something it'll automatically gets picked up for our kernel.
I sent mail (attached) to David Mosberger about this bug (see his
response below). We think that all it takes to fix this is to make
the names for glibc's siginfo.h fields the same as the kernel's
siginfo.h fields. We hacked up something to use the fields from
glibc's siginfo.h and that seems to work, so we assume that the fix
is a simple renaming (the standard macros don't work because the
names are wrong).
Please ask if this isn't clear.
From: David Mosberger [mailto:email@example.com]
Sent: Wednesday, March 10, 2004 2:13 PM
To: Hoeflinger, Jay P
Cc: David Mosberger
Subject: Re: FW: [Bug 107212] struct siginfo has changed from
previous versions of Linux
>>>>> On Mon, 8 Mar 2004 08:46:36 -0800, "Hoeflinger, Jay P"
Jay> We entered a bugzilla about this, but the response from Ulrich
Jay> Drepper (below) was that something has to be changed in the
Jay> kernel to make this work. Can you respond to that? I don't
Jay> know who is responsible for changing libc to get this to work.
I don't understand what he means. glibc has it's own file declaring
siginfo (/usr/include/bits/siginfo.h) and somebody will have to update
that file. There is nothing automatic there.
I'm not sure whether Jes Sorensen or Uli Drepper is the official
maintainer for ia64 glibc these days. But it would be one of them,
I'm pretty sure.
I have changed the name of the field in ia64's bits/siginfo.h and
added the access macro. It'll be in the next FC3 build and eventually
will make it into RHEL3. But the latter might be problematic since I
don't know whether all RHEL3 kernels support it.
I'll close the bug as UPSTREAM. If you desperately need this change
in RHEL3 reopen. But you should be able to get by with testing for
the absence of si_flags and then use the _si_pad0 value directly. But
portable but a stop-gap solution.