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: pinskia at gmail dot com
- Cc: carlos at redhat dot com, will dot newton at linaro dot org, libc-alpha at sourceware dot org
- Date: Tue, 10 Dec 2013 21:19:01 -0500 (EST)
- Subject: Re: Ruby testsuite failures because of pointer mangling on 32-bit ARM?
- Authentication-results: sourceware.org; auth=none
- References: <186C0AD8-CFA3-4EE1-AB18-1158E32F1F1B at gmail dot com> <20131210 dot 173622 dot 2212833574581899559 dot davem at davemloft dot net> <CA+=Sn1=4=+D579wNwB+GOZGKb2w2+QPBsg7AsX+wdcVfq8g=vQ at mail dot gmail dot com>
From: Andrew Pinski <pinskia@gmail.com>
Date: Tue, 10 Dec 2013 17:13:30 -0800
> On Tue, Dec 10, 2013 at 2:36 PM, David Miller <davem@davemloft.net> wrote:
>> From: pinskia@gmail.com
>> Date: Tue, 10 Dec 2013 11:57:03 -0800
>>
>>> Hmm, shouldn't ruby be using makecontext/restore context instead of
>>> setjmp/longjmp for this purpose? I think we should declare this as
>>> a bug in ruby.
>>
>> I honestly think that what Ruby is doing is quite reasonable.
>
> How so, jmp_buf is supposed to be an opaque structure. If a program
> depends on the context of an opaque structure, then it is a bug in the
> program rather than the library which changes what the opaque
> structure contains.
Addressing jmpbuf specifically, changing jmpbuf's layout would break
every GDB binary out there.
There are countless programs which want to see the frame pointer and
use jmpbuf plus target-specific implementations to fetch that value.
But that's not what Ruby is doing here, it is copying the stack frame
of a thread into another location and then using it in some way. In
fact I do not see any code in Ruby that actually looks into the jmpbuf
contents at all.