Re: siginfo fault addresses now apprently working on hppa

[Carlos O'Donell <carlos@baldric.uwo.ca>]

On Sat, Feb 07, 2004 at 01:42:13PM -0500, Camm Maguire wrote:
> Greetings!  GCL and its dependent programs (axiom, maxima, acl2) can
> make use of a more efficient garbage collection algorithm by marking
> pages read only, catching SIGSEGV on write attempt, reprotecting and
> marking the page, and then restarting.  This has not worked on the
> past on hppa as the fault address could not (at least to my knowledge)
> be recovered from the siginfo_t struct in the handler.  Now apparently
> si_ptr is correctly set, though si_addr, which the man page says
> should have the fault address (and does on many other platforms) does
> not.
> 
> Can I now reliably depend on this behavior and configure GCL on hppa
> to take advantage of this optimization?

Cam,

Thanks for your work on GCL. I've recently submitted some siginfo_t
fixes upstream, so I'll take a stab at enumerating your options.

What works and what doesn't work:
=================================

a. siginfo_t is properly delivered to 32-bit userspace from a 32-bit
   kernel. If it doesn't, please show me the example code, kernel config,
   and hardware used to run the test. This has always worked.

b. siginfo_t is *not* delivered properly to a 32-bit userspace from 
   a 64-bit 2.4 kernel. This has never worked.

c. siginfo_t is *correctly* delivered to a 32-bit userspace from a 
   64-bit 2.6 kernel. This started working in December when I put
   the fixes into cvs.parisc-linux.org. These fixes are going upstream.

To fix this for 2.4 would require backporting my compat_siginfo_t
patches, along with the rt_sigframe compat, and jejb's 64-bit process
changes (it's a lot of stuff). I currently don't have time for this :( 
if another hppa developer would like to do the backport I'd be happy to 
review.

In summary, you'd have to do atleast two runtime checks, perhaps
something like the following (though I don't quit know what to use
here):

	o If `uname -a` returns parisc64, and the kernel is 
          2.6.0 or greater, then you're golden, else disable
	  looking at siginfo_t information.

	o If `uname -a` returns parisc, then it has always worked.
	  Enable looking at siginfo_t information.

How you handle this is up to you :)

c.