This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Ruby testsuite failures because of pointer mangling on 32-bit ARM?
- From: David Miller <davem at davemloft dot net>
- To: carlos at redhat dot com
- Cc: pinskia at gmail dot com, will dot newton at linaro dot org, libc-alpha at sourceware dot org
- Date: Thu, 12 Dec 2013 13:20:53 -0500 (EST)
- Subject: Re: Ruby testsuite failures because of pointer mangling on 32-bit ARM?
- Authentication-results: sourceware.org; auth=none
- References: <20131210 dot 211901 dot 1840879367475720601 dot davem at davemloft dot net> <52A94FB5 dot 7060100 at redhat dot com> <20131212 dot 121441 dot 261870704107659875 dot davem at davemloft dot net>
From: David Miller <davem@davemloft.net>
Date: Thu, 12 Dec 2013 12:14:41 -0500 (EST)
> From: "Carlos O'Donell" <carlos@redhat.com>
> Date: Thu, 12 Dec 2013 00:55:01 -0500
>
>> It treats the jmp_buf as an array of VALUE sized pointers that
>> it can examine to determine if there are pointers to the heap.
>
> Sounds similar to what any other garbage collector will do, scan
> the processes address space looking for pointers.
>
> I'm pretty sure Boehm-GC does something similar, although perhaps
> it scans the entire process stack from the point in which it is
> called instead of using jmpbuf's to delineate spans of stack
> areas like Ruby does.
And, indirectly, realize that even a straight stack scan is going
to potentially break if you start mangling pointers in jmpbuf.
Consider the case where if the jmpbuf is on the processes stack, and
normally it would get scanned by GC and the pointer followed to find
memory references, and now that would not work because the pointer is
mangled.
I think all of these schemes are legitimate and erroneously broken
by pointer mangling.