This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] remote: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot with Abatron BDI emulator an error occurs:
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,
¤t_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 ?