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

["Maciej W. Rozycki" <macro at codesourcery dot com>]

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