breakpoints not working in gdbserver

breakpoints not working in gdbserver

[Simon Posnjak]

Hi all,

I'm trying out a cross-debuger for arm/ia32 development. I have build
gdb for arm that runs on ia32 (./configure --host=i686-pc-linux-gnu
--target=armv4l-unknown-linux --prefix=/usr/local/arm/
--exec-prefix=/usr/local/arm/ --program-prefix=arm-) 
and gdbserver for arm (sh configure --target=armv4l-unknown-linux). 

Then I strip the gdbserver and uploade it to the arm based bord and
run(access03 is the program I'm trying to debug):

# ./gdbserver host:33000 ./access03
Process ./access03 created; pid = 170

On the ia32, I fire up the gdb and do:
[root@klada access]# /usr/local/arm/gdb/bin/arm-gdb access03
GNU gdb 20020813
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=armv4l-unknown-linux"...
(gdb) set solib-absolute-prefix /dev/null
(gdb) set solib-search-path /staff2/4pot/buildroot/build/stage/lib
(gdb) target remote 10.1.0.2:33000
Remote debugging using 10.1.0.2:33000
0x40000d20 in ?? ()
(gdb) list 125
120
121     int exp_enos[]={EFAULT, 0};  /* List must end with 0 */
122
123     char * bad_addr = 0;
124
125     int main(int ac, char **av)
126     {
127         int lc;             /* loop counter */
128         char *msg;          /* message returned from parse_opts */
129
(gdb) br 127
Breakpoint 1 at 0x8fdc: file access03.c, line 127.
(gdb) c
Continuing.

Program received signal SIGILL, Illegal instruction.
0x40002b38 in _dl_debug_state ()
   from /staff2/4pot/buildroot/build/stage/lib/ld-uClibc.so.0
(gdb) bt
#0  0x40002b38 in _dl_debug_state ()
   from /staff2/4pot/buildroot/build/stage/lib/ld-uClibc.so.0
#1  0x40001c74 in _dl_parse_copy_information ()
   from /staff2/4pot/buildroot/build/stage/lib/ld-uClibc.so.0
(gdb)

The program dies with Illegal instruction - if I run it without
gdbserver it is working fine.

I'm using a home-made linux system:
kernel 2.4.18
uClibc 0.9.14
gcc-2.95.3

Is this maybe a problem with uclibc... or is this problem of
gdb(server)?

	Regards Simon

-- 
Simon Posnjak
http://klada.dyndns.org

Re: breakpoints not working in gdbserver

[Daniel Jacobowitz]

On Wed, Aug 14, 2002 at 12:30:42AM +0200, Simon Posnjak wrote:
> Hi all,
> 
> I'm trying out a cross-debuger for arm/ia32 development. I have build
> gdb for arm that runs on ia32 (./configure --host=i686-pc-linux-gnu
> --target=armv4l-unknown-linux --prefix=/usr/local/arm/
> --exec-prefix=/usr/local/arm/ --program-prefix=arm-) 
> and gdbserver for arm (sh configure --target=armv4l-unknown-linux). 

That's not right.  You have to configure gdbserver using
--host=armv4l-unknown-linux, not --target.

> Program received signal SIGILL, Illegal instruction.
> 0x40002b38 in _dl_debug_state ()
>    from /staff2/4pot/buildroot/build/stage/lib/ld-uClibc.so.0
> (gdb) bt
> #0  0x40002b38 in _dl_debug_state ()
>    from /staff2/4pot/buildroot/build/stage/lib/ld-uClibc.so.0
> #1  0x40001c74 in _dl_parse_copy_information ()
>    from /staff2/4pot/buildroot/build/stage/lib/ld-uClibc.so.0
> (gdb)
> 
> The program dies with Illegal instruction - if I run it without
> gdbserver it is working fine.
> 
> I'm using a home-made linux system:
> kernel 2.4.18
> uClibc 0.9.14
> gcc-2.95.3
> 
> Is this maybe a problem with uclibc... or is this problem of
> gdb(server)?

Now, I just checked, and the FSF tree does indeed have the correct
breakpoint instruction on ARM.  And GDB is placing that breakpoint
anyway, not gdbserver.  I assume you're actually running a Linux kernel
- Linux has a different breakpoint convention from ARM hardware.

Need a little more information.  Please set remote_debug to 1 and
rebuild gdbserver, and send the output...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

ARM/Linux OSABI problems (was Re: breakpoints not working in gdbserver)

[Daniel Jacobowitz]

On Wed, Aug 14, 2002 at 12:30:42AM +0200, Simon Posnjak wrote:
> Hi all,
> 
> I'm trying out a cross-debuger for arm/ia32 development. I have build
> gdb for arm that runs on ia32 (./configure --host=i686-pc-linux-gnu
> --target=armv4l-unknown-linux --prefix=/usr/local/arm/
> --exec-prefix=/usr/local/arm/ --program-prefix=arm-) 
> and gdbserver for arm (sh configure --target=armv4l-unknown-linux). 
> 
> Then I strip the gdbserver and uploade it to the arm based bord and
> run(access03 is the program I'm trying to debug):
> 
> # ./gdbserver host:33000 ./access03
> Process ./access03 created; pid = 170

...

The interesting line in the debug output Simon sent me is:
getpkt ("M40002b34,4:fedeffe7");  [sending ack]

That's not an arm-linux breakpoint, it's an ARM breakpoint.  That's why
it isn't working.

Simon, you need to debug the host GDB (particularly
gdbarch_lookup_osabi) and try to establish why it is not selecting the
Linux ABI.

> I'm using a home-made linux system:
> kernel 2.4.18
> uClibc 0.9.14
> gcc-2.95.3
> 
> Is this maybe a problem with uclibc... or is this problem of
> gdb(server)?

... wait!  I know what's wrong.  Does uClibc provide a .note.ABI-tag
section, like glibc does?  If not, that needs to be corrected, or GDB
needs to find some other way to recognize uClibc binaries.

(I should also test kernel debugging using an arm-linux GDB at some
point.  It used to work, which means that kgdb also expects the linux
ABI breakpoint, but the kernel certainly doesn't (and shouldn't) have
a .note.ABI-tag marking indicating it is a Linux userland binary.)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: ARM/Linux OSABI problems (was Re: breakpoints not working in gdbserver)

[William A. Gatliff]

Daniel:


> (I should also test kernel debugging using an arm-linux GDB at some
> point.  It used to work, which means that kgdb also expects the linux
> ABI breakpoint, but the kernel certainly doesn't (and shouldn't) have
> a .note.ABI-tag marking indicating it is a Linux userland binary.)


Hmmm... where did you get an arm-linux kernel stub?  I'd like one of those!

b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

Re: ARM/Linux OSABI problems (was Re: breakpoints not working in gdbserver)

[Andrew Cagney]

> 
> 
> ... wait!  I know what's wrong.  Does uClibc provide a .note.ABI-tag
> section, like glibc does?  If not, that needs to be corrected, or GDB
> needs to find some other way to recognize uClibc binaries.
> 
> (I should also test kernel debugging using an arm-linux GDB at some
> point.  It used to work, which means that kgdb also expects the linux
> ABI breakpoint, but the kernel certainly doesn't (and shouldn't) have
> a .note.ABI-tag marking indicating it is a Linux userland binary.)

I'll also bug report:

	(gdb) set architecture <machine> <osabi>

the user should be able to force the <osabi> so that they can extract 
themselves from situtations such as this.

Andrew

Re: ARM/Linux OSABI problems (was Re: breakpoints not working in gdbserver)

[Simon Posnjak]

On Wed, 2002-08-14 at 15:10, Daniel Jacobowitz wrote:
> ... wait!  I know what's wrong.  Does uClibc provide a .note.ABI-tag
> section, like glibc does?  If not, that needs to be corrected, or GDB
> needs to find some other way to recognize uClibc binaries.

You're right(objdump):
arm-linux:
**********
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .interp       00000013  000080f4  000080f4  000000f4  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .note.ABI-tag 00000020  00008110  00008110  00000110  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .hash         00000198  00008130  00008130  00000130  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .dynsym       000003f0  000082c8  000082c8  000002c8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .dynstr       000001fd  000086b8  000086b8  000006b8  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .gnu.version  0000007e  000088b6  000088b6  000008b6  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .gnu.version_r 00000030  00008934  00008934  00000934  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .rel.got      00000008  00008964  00008964  00000964  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .rel.bss      00000020  0000896c  0000896c  0000096c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .rel.plt      000001c0  0000898c  0000898c  0000098c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 10 .init         00000018  00008b4c  00008b4c  00000b4c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 11 .plt          00000390  00008b64  00008b64  00000b64  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 12 .text         000047d8  00008ef4  00008ef4  00000ef4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 13 .fini         00000014  0000d6cc  0000d6cc  000056cc  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 14 .rodata       00001564  0000d6e0  0000d6e0  000056e0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 15 .data         00000168  00016c44  00016c44  00006c44  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 16 .ctors        00000008  00016dac  00016dac  00006dac  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 17 .dtors        00000008  00016db4  00016db4  00006db4  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 18 .got          000000f0  00016dbc  00016dbc  00006dbc  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 19 .dynamic      000000a0  00016eac  00016eac  00006eac  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 20 .sbss         00000000  00016f4c  00016f4c  00006f50  2**0
                  CONTENTS
 21 .bss          00004b24  00016f50  00016f50  00006f50  2**4
                  ALLOC
 22 .comment      000001ee  00000000  00000000  00006f50  2**0
                  CONTENTS, READONLY
uclibc:
*******
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .interp       00000014  000080d4  000080d4  000000d4  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .hash         00000704  000080e8  000080e8  000000e8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .dynsym       00000fa0  000087ec  000087ec  000007ec  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .dynstr       00000824  0000978c  0000978c  0000178c  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .rel.bss      00000048  00009fb0  00009fb0  00001fb0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .rel.plt      00000700  00009ff8  00009ff8  00001ff8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .plt          00000e10  0000a6f8  0000a6f8  000026f8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  7 .text         00037560  0000b508  0000b508  00003508  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  8 .rodata       0000ccd0  00042a68  00042a68  0003aa68  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .data         00000778  00057738  00057738  00047738  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 10 .got          00000390  00057eb0  00057eb0  00047eb0  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 11 .dynamic      00000078  00058240  00058240  00048240  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 12 .sbss         00000000  000582b8  000582b8  000482b8  2**0
                  CONTENTS
 13 .bss          00007d20  000582b8  000582b8  000482b8  2**3
                  ALLOC

What do you think what would be the best solution? I liked the idea that
Andrew Cagney give:

>        (gdb) set architecture <machine> <osabi>
>
>the user should be able to force the <osabi> so that they can extract
>themselves from situtations such as this.

I will do this if you think it is a good idea. (Plese give me some
pointers where to start becouse I'm new to gdb sources)

	Regards Simon

-- 
Simon Posnjak
http://klada.dyndns.org