From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12058 invoked by alias); 23 Jun 2009 05:09:43 -0000 Received: (qmail 12047 invoked by uid 22791); 23 Jun 2009 05:09:41 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 23 Jun 2009 05:09:36 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MIyGA-0006CA-Mn for gdb@sources.redhat.com; Tue, 23 Jun 2009 05:09:30 +0000 Received: from 67-220-17-45.usiwireless.com ([67.220.17.45]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Jun 2009 05:09:30 +0000 Received: from grant.b.edwards by 67-220-17-45.usiwireless.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Jun 2009 05:09:30 +0000 To: gdb@sources.redhat.com From: Grant Edwards Subject: Re: Troubleshooting broken gdbserver/remote-target Date: Tue, 23 Jun 2009 05:09:00 -0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: slrn/pre0.9.9-102 (Linux) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00219.txt.bz2 On 2009-06-23, Grant Edwards wrote: > But when the program is stopped while blocked in a call to > read() inside gets(), gdb throws up its hands: [...] > GNU gdb 6.8 > [...] > This GDB was configured as "--host=i386-pc-linux-gnu --target=arm-linux-uclibc". > [New Thread 815] > 0x40001350 in _start () at ldso/ldso/arm/elfinterp.c:332 > 332 } > (gdb) c > Continuing. > ^C > Program received signal SIGINT, Interrupt. > 0x40031914 in ?? () > (gdb) bt > #0 0x40031914 in ?? () > > > If I look at the maps or smaps file for the process, address > 0x40031914 is clearly in uclibc.so: > > 40025000-4008a000 r-xp 00000000 01:00 637 /lib/libuClibc-0.9.30.1.so > > 40031914 is offset 0x0000c914 in /lib/libuClibc-0.9.30.1.so, and > looking at the symbols in that file shows that offset 0x0000c914 > is in __libc_read() [...] > Why can't gdb figure out that the process is blocked in > __libc_read() and print a proper backtrace? I think I've found a clue why gdb is unable to figure out what function contains address 0x40031914. Gdb seems to be aware of the mappig of only one of the library files (/lib/ld-uClibc-0.9.30.1.so), and doesn't appear to know that libuClibc-0.9.30.1.so is mapped: (gdb) info file Symbols from "/home/grante/hello/mecho". Remote serial target in gdb-specific protocol: Debugging a target over a serial line. While running this, GDB does not access memory from... Local exec file: `/home/grante/hello/mecho', file type elf32-littlearm. Entry point: 0x8420 0x000080f4 - 0x00008108 @ 0x000000f4 is .interp 0x00008108 - 0x00008160 @ 0x00000108 is .hash 0x00008160 - 0x00008270 @ 0x00000160 is .dynsym 0x00008270 - 0x0000833a @ 0x00000270 is .dynstr 0x0000833a - 0x0000835c @ 0x0000033a is .gnu.version 0x0000835c - 0x0000837c @ 0x0000035c is .gnu.version_r 0x0000837c - 0x000083ac @ 0x0000037c is .rel.plt 0x000083ac - 0x000083c4 @ 0x000003ac is .init 0x000083c4 - 0x00008420 @ 0x000003c4 is .plt 0x00008420 - 0x000085a0 @ 0x00000420 is .text 0x000085a0 - 0x000085b4 @ 0x000005a0 is .fini 0x000085b4 - 0x000085b8 @ 0x000005b4 is .eh_frame 0x000105b8 - 0x000105c0 @ 0x000005b8 is .ctors 0x000105c0 - 0x000105c8 @ 0x000005c0 is .dtors 0x000105c8 - 0x000105cc @ 0x000005c8 is .jcr 0x000105cc - 0x00010684 @ 0x000005cc is .dynamic 0x00010684 - 0x000106a8 @ 0x00000684 is .got 0x000106a8 - 0x000106b8 @ 0x000006a8 is .data 0x000106b8 - 0x00010ad8 @ 0x000006b8 is .bss 0x400000d4 - 0x40000240 @ 0x000000d4 is .hash in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0 0x40000240 - 0x40000580 @ 0x00000240 is .dynsym in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0 0x40000580 - 0x40000888 @ 0x00000580 is .dynstr in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0 0x40000888 - 0x40000930 @ 0x00000888 is .rel.dyn in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0 0x40000930 - 0x40008b70 @ 0x00000930 is .text in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0 0x40008b70 - 0x40008ffc @ 0x00008b70 is .rodata in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0 0x40011f14 - 0x40011f18 @ 0x00009f14 is .dtors in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0 0x40011f18 - 0x40011fa8 @ 0x00009f18 is .dynamic in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0 0x40011fa8 - 0x40012000 @ 0x00009fa8 is .got in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0 0x40012000 - 0x40012008 @ 0x0000a000 is .data in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0 0x40012008 - 0x4001205c @ 0x0000a008 is .bss in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0 Here's the contents of /proc//maps for the process being debuged: 00008000-00009000 r-xp 00000000 01:00 130 /usr/bin/mecho 00010000-00011000 rw-p 00000000 01:00 130 /usr/bin/mecho 40000000-40009000 r-xp 00000000 01:00 642 /lib/ld-uClibc-0.9.30.1.so 40009000-4000a000 rw-p 40009000 00:00 0 40011000-40012000 r--p 00009000 01:00 642 /lib/ld-uClibc-0.9.30.1.so 40012000-40013000 rw-p 0000a000 01:00 642 /lib/ld-uClibc-0.9.30.1.so 40013000-4001c000 r-xp 00000000 01:00 212 /lib/libgcc_s.so.1 4001c000-40024000 ---p 4001c000 00:00 0 40024000-40025000 rw-p 00009000 01:00 212 /lib/libgcc_s.so.1 40025000-4008a000 r-xp 00000000 01:00 637 /lib/libuClibc-0.9.30.1.so 4008a000-40092000 ---p 4008a000 00:00 0 40092000-40093000 r--p 00065000 01:00 637 /lib/libuClibc-0.9.30.1.so 40093000-40094000 rw-p 00066000 01:00 637 /lib/libuClibc-0.9.30.1.so 40094000-40098000 rw-p 40094000 00:00 0 be98b000-be9a0000 rw-p befeb000 00:00 0 [stack] Gdb figured out the /lib/ld-uClibc-0.9.30.1.so, but it's missing /lib/libgcc_s.so.1 and /lib/libuClibc-0.9.30.1.so. What would cause gdb to miss out on the fact that /lib/libuClibc-0.9.30.1.so is mapped? Where does gdb get mapping info? -- Grant