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

Pedro Alves
2012-06-08T12:10:20Z

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