[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Re: siginfo fault addresses now apprently working on hpp
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] Re: siginfo fault addresses now apprently working on hppa |
Date: |
12 Feb 2004 16:05:32 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings, and thanks for your feedback! I notice sarti has the same
kernel. I'll change to si_addr, but this will mean that the
autobuilders will turn off SGC with my new patch on maxima/acl2/axiom.
Users running the binaries on working kernels could reenable it if
they knew how (i.e. (si:;sgc-on t)). Any idea of what Debian hppa
users are likely to run? In any case, the code will be ready when the
kernels catch up.
Carlos O'Donell <address@hidden> writes:
> Cam,
>
> > > 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.
> > >
> >
> > Well, I'm not sure how long is meant by always, but lets forget about
> > the past for the moment. Right now on paer I can get the address in
> > ((siginfo_t *)code)->si_ptr
> > where the handler is defined as
> > void
> > memprotect_handler(int sig, long code, void *scp, char *addr)
> > and setup with SA_RESTART and SA_SIGINFO. On most machines its under
> > ((siginfo_t *)code)->si_addr
> > but not on paer. I can show you a gdb trace if you need.
>
> si_ptr is only valid for POSIX real-time signals, don't use that.
> paer is a 64-bit box running 2.4.23-pa5, and thus does not have the
> fixes required. The fact that si_ptr works is a *complete* fluke, the
> kernel has shifted all values in the structure. You are really reading a
> 64-bit version of the structure.
>
> Please apply pressure to have paer updated to a new 2.6.x kernel :)
>
> > Thanks for this jog. This has been on my todo list for sometime now.
> > I've just implemented a runtime test for the fault recovery
> > mechanism. I'm not checking kernel versions per se, just the compile
> > time determined code snippet for recovering the fault address on the
> > runtime kernel. Here's the outline:
>
> It looks fine, you just can't run that code on a 64-bit box without a
> 2.6.1 or newer kernel from cvs.parisc-linux.org.
I think the code will run, discover the fault address is wrong, and
disable the feature. That's the idea anyway.
Take care,
>
> c.
>
>
>
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah