Red Hat Bugzilla – Bug 107212
struct siginfo has changed from previous versions of Linux
Last modified: 2007-11-30 17:06:53 EST
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): EL3.0 RC1 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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 in /usr/src/linux/include/asm-ia64/siginfo.h. 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 to users?
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. Jay -----Original Message----- From: David Mosberger [mailto:davidm@napali.hpl.hp.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.p.hoeflinger@intel.com> said: 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. --david
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.