Re: [PATCH] remote: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot with Abatron BDI emulator an error occurs:

[Joakim Tjernlund <joakim.tjernlund@transmode.se>]

Pedro Alves <palves@redhat.com> wrote on 2012/06/01 16:08:23:
>
> On 06/01/2012 02:36 PM, Joakim Tjernlund wrote:
>
> > ..
> > (gdb) tar remote bdi:2001
> > Remote debugging using bdi:2001
> > 0xeff80050 in ?? ()
> > (gdb) mon reset
> > (gdb) cont
> > Continuing.
> > Warning:
> > Cannot insert breakpoint -1.
> > Error accessing memory address 0xc0000000: Unknown error 4294967295.
> >
> > (gdb) maintenance info breakpoints
> > Num     Type           Disp Enb Address    What
> > -1      shlib events   keep y   0xc0000000 <_stext> inf 1
> >
> > gdb mistakenly inserts a special shared library BP even though
> > there area no such libs in either linux or u-boot.
>
>
> GDB has no special knowledge of the Linux kernel, nor of u-boot.
> A GNU/Linux targeted GDB (*-*-linux-gnu) recognizes, and knows how to
> debug user space applications.  If the kernel binary or the u-boot binary
> look very much like GNU/Linux user space programs, the *-*-linux-gnu targeted
> GDB will assume that's what they are.  If you used a bare metal elf/eabi
> targeted GDB, which is really what those programs are, you'd not see this.

Yes you would, the error comes from this in solibsvr4.c:
static const char * const bkpt_names[] =
{
  "_start",
  "__start",
  "main",
  NULL
};

...

 if (!current_inferior ()->attach_flag)
    {
      for (bkpt_namep = bkpt_names; *bkpt_namep != NULL; bkpt_namep++)
	{
	  msymbol = lookup_minimal_symbol (*bkpt_namep, NULL, symfile_objfile);
	  if ((msymbol != NULL) && (SYMBOL_VALUE_ADDRESS (msymbol) != 0))
	    {
	      sym_addr = SYMBOL_VALUE_ADDRESS (msymbol);
	      sym_addr = gdbarch_convert_from_func_ptr_addr (target_gdbarch,
							     sym_addr,
							     &current_target);
	      create_solib_event_breakpoint (target_gdbarch, sym_addr);
	      return 1;
	    }
	}
    }

Just because a executable has a _start/__start/main in it, it doesn't  mean it uses
shared libs. I think this code assumes way too much, it is a last resort if everything
else fails.
The code tries to avoid attached targets but fails because it isn't attached yet

>
> > Fix this by explicitly informing remote_add_inferior() that
> > the remote is attached.
>
>
> NAK.  This is not a "fix", it's papering over the problem, and
> regresses GDB.  It makes GDB always detach on quit, instead of asking
> the remote end whether it is "attached" or whether it has "spawned"
> the inferior.

OK, that is fine. I don't know this code. Any suggestion ?