Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot

[Pedro Alves <palves at redhat dot com>]

On 06/07/2012 12:59 AM, Maciej W. Rozycki wrote:

> On Fri, 1 Jun 2012, Pedro Alves wrote:
> 
>>>> --- a/gdb/solib-svr4.c
>>>> +++ b/gdb/solib-svr4.c
>>>> @@ -1707,7 +1707,7 @@ enable_break (struct svr4_info *info, int from_tty)
>>>>  	}
>>>>      }
>>>>
>>>> -  if (!current_inferior ()->attach_flag)
>>>> +  if (interp_name != NULL && !current_inferior ()->attach_flag)
>>>>      {
>>>>        for (bkpt_namep = bkpt_names; *bkpt_namep != NULL; bkpt_namep++)
>>>>  	{
>>>
>>> It has a regression in the case below.
>>>
>>> OTOH one has to strip _start to make it a regression as with _start GDB did not
>>> catch startup libraries even before.
>>
>>
>> Yeah, that's a really contrived example.  You're relying on stopping at main,
>> not when the DSO is really loaded (_dl_debug_state) to set the breakpoint.
>> I can see _start not existing, with the entry point named something else,
>> but if you strip your static binary to miss _dl_debug_state, you won't get
>> main either.  (and then static binaries that dlopen aren't something you'd
>> want to do normally.)
> 
>  Not really that contrived, glibc itself will dlopen(3) any NSS modules 
> required even from static binaries (unless you configure the library in a 
> non-standard way, that is yet more horrible a case) and I reckon there are 
> real life examples that make use of that feature (and explicit provisions 
> in glibc to handle a static and a dynamic copy of libc code to be loaded 
> both at once; it matters for things like malloc(3) if nothing else).


That's basically the same thing.  With either that, or explicitly linking a
program that calls dlopen with "-static -ldl", you end up with "_dl_debug_state"
built into your binary, so the "_start" or "main" "fallbacks" are
never triggered.  If you strip your binary, GDB won't find "_dl_debug_state",
but then it won't find "_start" nor "main" either!  So it is a contrived
example to strip "_dl_debug_state" and "_start" but not "main", because
that's not something that is natural to do.

>  If this scenario cannot be handled as one would expect and in a clean 
> way, then perhaps we need to arrange for another shared-library event hook 
> in glibc to be exported from static dlopen(3) code (e.g. a special section 
> that won't ever be stripped unless tried really, really hard).


"_dl_debug_state" ends up available on static links too, I don't see what
is there to do.

-- 
Pedro Alves