Re: [RFA] Fix solib-precsave.exp,solib-reverse.exp

[Doug Evans <dje at google dot com>]

On Mon, Apr 15, 2013 at 10:33 AM, Pedro Alves <palves@redhat.com> wrote:
> On 04/13/2013 12:13 AM, Doug Evans wrote:
>> Hi.
>>
>> These two tests are failing for me.
>> They make the assumption that debug info for libc isn't installed.
>>
>> To fix this I've created a library of wrappers for the affected libc
>> functions and compiled it without debug info.
>>
>> Ok to check in?
>
> This the certainly the right idea for fixing the problem, but it took me a
> while to realize that the fact that the functions currently called are
> printf and sleep, and that the new library has wrappers for those has no
> importance.  They really are just used as proxy for "functions in library
> with no debug info".  Not even the output of printf is used.  I think that
> calling the library a syscall wrapper makes it prone to causing such doubt
> and confusion in other readers (of either the patch or the resulting code
> in the tree), as it has caused me.
>
> How about we just call it "shr1", and have it export some non-libc related
> functions like e.g., "shr1_foo" and "shr1_bar"?

Blech.  That's how I originally had it.
The original code used printf and sleep and I figured someone would
want to keep them.
I don't have a preference for either way.  Anyone else?
In any case we need to document that one cannot call libc functions
(or similar) as is.

>>  int main ()
>> @@ -27,16 +31,25 @@ int main ()
>>    char* cptr = "String 1";
>>    int b[2] = {5,8};
>>
>> +  /* Call these functions once before we start testing so that they get
>> +     resolved by the dynamic loader.  If the system has debug info for
>> +     the dynamic loader installed, reverse-stepping for the first call
>> +     will otherwise record being in the dynamic loader, which is not what
>
> reverse-stepping doesn't record.  Did you mean "report", or even
> "reverse-stepping the first call will otherwise stop in the
> dynamic loader", perhaps?

Yeah.