sigsegv on s390 only giving start address of page in segv handler
Bruno Haible <bruno at clisp.org> writes:
> When you wrote to <bug-libsigsegv-antispam at antispam.gnu.org> you didn't remove
> the "antispam" words from the address.
>> libsigsegv doesn't cope well with s390 at the moment. This is caused
>> by the fact, that linux masks the address for sigsegv:
>> mm/fault.c:#define __FAIL_ADDR_MASK 0x7ffff000
>> So the last 12 bit of information are lost.
> Thanks for the analysis. Indeed at least the 'sigsegv1' test will fail in this
> Have you reported the problem to the linux-kernel mailing list, or to the
> maintainers of the s390 part of Linux?
<waldi> oh. there is a hint that the complete address may be incorrect (>= the actual address) in case of cpu retries
So this might be unavoidable. I'll ask on the mailinglist nontheless.
>> Forcing libsigsegv to use
>> POSIX signal handlers othewise makes a library that passes all the tests
>> apart from the exact fault location.
> That sounds promising, if the kernel problem was fixed.
>> Now I'm wondering of software depending on libsigsegv won't work on s390
>> or maybe the correct page is still enough information for dependencies
>> like clisp to work -- in that case a "fix" would be rather easy.
> clisp (and probably other software too) will compile and work also when
> the installed <sigsegv.h> file does not define HAVE_SIGSEGV_RECOVERY or
> HAVE_STACK_OVERFLOW_RECOVERY. But the functionality will be a bit degraded.
> For clisp, it means that generational GC will not be compiled into clisp
> if HAVE_SIGSEGV_RECOVERY is not defined, and endless recursions may cause
> a crash if HAVE_STACK_OVERFLOW_RECOVERY is not defined.
Hm so one would just at least make it build with these flags disabled
for a start. Can't promise anything about my spare time for digging into
this in the near future unfortunately.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 838 bytes
Desc: not available