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

Maciej W. Rozycki
2012-06-07T00:00:11Z

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).

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). Of course
as soon as one dynamic module has been loaded, then there'll be a copy of
the dynamic linker most likely pulled in too with its own shared-library
event hook (I think shared modules that have not been linked against
libc.so have not been supported beyond libc 5 on glibc systems, i.e. from
glibc 2.0 on; this may have to be double-checked though).

Can't speak of other libc implementations.

Maciej