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

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

[Joakim Tjernlund]

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

Fix this by explicitly informing remote_add_inferior() that
the remote is attached.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
 remote.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/remote.c b/remote.c
index 04b818f..f06c119 100644
--- a/remote.c
+++ b/remote.c
@@ -3293,7 +3293,7 @@ remote_start_remote (int from_tty, struct target_ops *target, int extended_p)
       /* Now, if we have thread information, update inferior_ptid.  */
       inferior_ptid = remote_current_thread (inferior_ptid);
 
-      remote_add_inferior (ptid_get_pid (inferior_ptid), -1);
+      remote_add_inferior (ptid_get_pid (inferior_ptid), 1);
 
       /* Always add the main thread.  */
       add_thread_silent (inferior_ptid);
-- 
1.7.3.4

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

[Pedro Alves]

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.

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

-- 
Pedro Alves

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

[Joakim Tjernlund]

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 ?

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

[Pedro Alves]

On 06/01/2012 03:38 PM, Joakim Tjernlund wrote:

>> 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
> };


No you wouldn't, because solib-svr4 is not used (or even compiled in)
on a bare metal targeted GDB.

-- 
Pedro Alves

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

[Joakim Tjernlund]

Pedro Alves <palves@redhat.com> wrote on 2012/06/01 16:40:38:
>
> On 06/01/2012 03:38 PM, Joakim Tjernlund wrote:
>
> >> 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
> > };
>
>
> No you wouldn't, because solib-svr4 is not used (or even compiled in)
> on a bare metal targeted GDB.

Ah, right you are. So this "just" hits svr4 users. Anyhow, its is a problem and
needs to be fixed(in svr4 lib I guess)

 Jocke

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 wrote on 2012/06/01 16:48:00:
>
> Pedro Alves <palves@redhat.com> wrote on 2012/06/01 16:40:38:
> >
> > On 06/01/2012 03:38 PM, Joakim Tjernlund wrote:
> >
> > >> 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
> > > };
> >
> >
> > No you wouldn't, because solib-svr4 is not used (or even compiled in)
> > on a bare metal targeted GDB.

> Ah, right you are. So this "just" hits svr4 users. Anyhow, its is a problem and
> needs to be fixed(in svr4 lib I guess)

hmm, is there some variable I can set in gdbinit?

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

[Joakim Tjernlund]

Pedro Alves <palves@redhat.com> wrote on 2012/06/01 16:40:38:
>
> On 06/01/2012 03:38 PM, Joakim Tjernlund wrote:
>
> >> 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
> > };
>
>
> No you wouldn't, because solib-svr4 is not used (or even compiled in)
> on a bare metal targeted GDB.

One suggesting I got is to wrap this last test with
if (interp_name) /* Check if there is a ld.so at all */
    if (!current_inferior ()->attach_flag)
     ...
    }

What do you think about that?

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

[Pedro Alves]

On 06/01/2012 03:53 PM, Joakim Tjernlund wrote:

> Pedro Alves <palves@redhat.com> wrote on 2012/06/01 16:40:38:
>>
>> On 06/01/2012 03:38 PM, Joakim Tjernlund wrote:
>>
>>>> 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
>>> };
>>
>>
>> No you wouldn't, because solib-svr4 is not used (or even compiled in)
>> on a bare metal targeted GDB.
> 
> One suggesting I got is to wrap this last test with
> if (interp_name) /* Check if there is a ld.so at all */
>     if (!current_inferior ()->attach_flag)
>      ...
>     }
> 
> What do you think about that?


That makes sense.

-- 
Pedro Alves

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

[Joakim Tjernlund]

Pedro Alves <palves@redhat.com> wrote on 2012/06/01 16:55:48:

> From: Pedro Alves <palves@redhat.com>
> To: Joakim Tjernlund <joakim.tjernlund@transmode.se>,
> Cc: gdb-patches@sourceware.org
> Date: 2012/06/01 16:56
> Subject: Re: [PATCH] remote: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot with Abatron BDI emulator an error occurs:
>
> On 06/01/2012 03:53 PM, Joakim Tjernlund wrote:
>
> > Pedro Alves <palves@redhat.com> wrote on 2012/06/01 16:40:38:
> >>
> >> On 06/01/2012 03:38 PM, Joakim Tjernlund wrote:
> >>
> >>>> 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
> >>> };
> >>
> >>
> >> No you wouldn't, because solib-svr4 is not used (or even compiled in)
> >> on a bare metal targeted GDB.
> >
> > One suggesting I got is to wrap this last test with
> > if (interp_name) /* Check if there is a ld.so at all */
> >     if (!current_inferior ()->attach_flag)
> >      ...
> >     }
> >
> > What do you think about that?
>
>
> That makes sense.

Done, see new patch on list