public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "redwindwanderer at gmail dot com" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug c++/14458] New: GDB on Pandaboard: can't single-step code (next) Date: Sun, 12 Aug 2012 16:24:00 -0000 [thread overview] Message-ID: <bug-14458-4717@http.sourceware.org/bugzilla/> (raw) http://sourceware.org/bugzilla/show_bug.cgi?id=14458 Bug #: 14458 Summary: GDB on Pandaboard: can't single-step code (next) Product: gdb Version: 7.4 Status: NEW Severity: critical Priority: P2 Component: c++ AssignedTo: unassigned@sourceware.org ReportedBy: redwindwanderer@gmail.com Classification: Unclassified Hi there, I'm having a very hard time trying to get GDB working right on my Pandaboard (an ARM based SBC, see www.pandaboard.org). It won't allow me to single-step thru with code with "next" as I usually do in my X86 pc. It happens in shared library code I'm debugging (SDL_fbevents.c). Both the program using the library and the library itself are compiled with the gcc CFLAGS and CXXFLAGS "-g -O0", so they contain degub symbols and they should be pretty much un-optimized. I can place a bp and it does stop where I want, but after I ussie a "next" or two gdb goes wild and runs the rest of the program without my control. Here's a typical gdb session. I end the program manually after the strange "jump" takes place and kicks me out of the function I'd like to single-step. [code] manuel@panda ~/parallax-2 $ gdb parallax2 GNU gdb (Gentoo 7.4.1 p2) 7.4.1 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "armv7a-hardfloat-linux-gnueabi". For bug reporting instructions, please see: <http://bugs.gentoo.org/>... Reading symbols from /home/manuel/parallax-2/parallax2...done. (gdb) b SDL_fbevents.c : 248 No source file named SDL_fbevents.c. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (SDL_fbevents.c : 248) pending. (gdb) r Starting program: /home/manuel/parallax-2/parallax2 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". Breakpoint 1, KMS_OpenKeyboard (this=0x13008) at ./src/video/kms/SDL_fbevents.c:248 248 if ( keyboard_fd < 0 ) { (gdb) n 254 tty0_fd = -1; (gdb) n 255 for ( i=0; tty0[i] && (tty0_fd < 0); ++i ) { (gdb) n KMS_VideoInit (this=0x13008, vformat=0xbefff330) at ./src/video/kms/SDL_fbvideo.c:465 465 KMS_VideoQuit(this); (gdb) bt #0 KMS_VideoInit (this=0x13008, vformat=0xbefff330) at ./src/video/kms/SDL_fbvideo.c:465 #1 0xb6f8eecc in SDL_VideoInit (driver_name=0x0, flags=0) at ./src/video/SDL_video.c:249 #2 0xb6f4f3ec in SDL_InitSubSystem (flags=32) at ./src/SDL.c:89 #3 0xb6f4f584 in SDL_Init (flags=32) at ./src/SDL.c:162 #4 0x00008984 in main (argc=1, argv=0xbefff574) at parallax2.c:187 (gdb) q A debugging session is active. Inferior 1 [process 1369] will be killed. Quit anyway? (y or n) y [/code] Here's the full SDL_fbevents.c, so you can look what GDB is ignoring and jumping over. Go to line 248 to see where I placed my bp to start the single-stepping: [url]http://svn.libsdl.org/tags/SDL/merges/trunk-1.3-3/src/video/fbcon/SDL_fbevents.c[/url] The library is not stripped: [code] manuel@panda ~/parallax-2 $ file /usr/lib/libSDL-1.2.so.0.11.4 /usr/lib/libSDL-1.2.so.0.11.4: ELF 32-bit LSB shared object, ARM, verscally linked, not stripped [/code] ...and, as I said, it's compiled with "-d -O0". I got sure every gcc command in the make process had the "-g -O0" parameters. The code lines seem to be contiguous, here's how objdump -dl on /usr/lib/libSDL-1.2.so.0.11.4 looks around the line I start my single-stepping on (SDL_fbevents.c:248): [code] manuel@panda ~/parallax-2 $ objdump -dl /usr/lib/libSDL-1.2.so.0.11.4 |grep -50 SDL_events.c:248 ffa0: e08f3003 add r3, pc, r3 ffa4: e3a02000 mov r2, #0 ffa8: e5832000 str r2, [r3] /home/manuel/SDL-1.2.15/./src/events/SDL_events.c:234 ffac: ebffffdb bl ff20 <SDL_StopEventLoop> /home/manuel/SDL-1.2.15/./src/events/SDL_events.c:237 ffb0: e59f3100 ldr r3, [pc, #256] ; 100b8 <SDL_StartEventLoop+0x13c> ffb4: e08f3003 add r3, pc, r3 ffb8: e3a02000 mov r2, #0 ffbc: e5832000 str r2, [r3] /home/manuel/SDL-1.2.15/./src/events/SDL_events.c:238 ffc0: e59f30f4 ldr r3, [pc, #244] ; 100bc <SDL_StartEventLoop+0x140> ffc4: e08f3003 add r3, pc, r3 ffc8: e1a00003 mov r0, r3 ffcc: e3a01001 mov r1, #1 ffd0: e3a02020 mov r2, #32 ffd4: ebffd2b7 bl 4ab8 <_init+0x284> /home/manuel/SDL-1.2.15/./src/events/SDL_events.c:239 ffd8: e59f30e0 ldr r3, [pc, #224] ; 100c0 <SDL_StartEventLoop+0x144> ffdc: e08f3003 add r3, pc, r3 ffe0: e3e02000 mvn r2, #0 ffe4: e5832000 str r2, [r3] /home/manuel/SDL-1.2.15/./src/events/SDL_events.c:241 ffe8: e59f30d4 ldr r3, [pc, #212] ; 100c4 <SDL_StartEventLoop+0x148> ffec: e08f3003 add r3, pc, r3 fff0: e5933000 ldr r3, [r3] fff4: e3c32a02 bic r2, r3, #8192 ; 0x2000 fff8: e59f30c8 ldr r3, [pc, #200] ; 100c8 <SDL_StartEventLoop+0x14c> fffc: e08f3003 add r3, pc, r3 10000: e5832000 str r2, [r3] /home/manuel/SDL-1.2.15/./src/events/SDL_events.c:242 10004: e59f30c0 ldr r3, [pc, #192] ; 100cc <SDL_StartEventLoop+0x150> 10008: e08f3003 add r3, pc, r3 1000c: e3a02000 mov r2, #0 10010: e5c3200d strb r2, [r3, #13] /home/manuel/SDL-1.2.15/./src/events/SDL_events.c:245 10014: e3a03000 mov r3, #0 10018: e50b3008 str r3, [fp, #-8] /home/manuel/SDL-1.2.15/./src/events/SDL_events.c:246 1001c: ebfffe0a bl f84c <SDL_AppActiveInit> 10020: e1a03000 mov r3, r0 10024: e51b2008 ldr r2, [fp, #-8] 10028: e0823003 add r3, r2, r3 1002c: e50b3008 str r3, [fp, #-8] /home/manuel/SDL-1.2.15/./src/events/SDL_events.c:247 10030: eb000330 bl 10cf8 <SDL_KeyboardInit> 10034: e1a03000 mov r3, r0 10038: e51b2008 ldr r2, [fp, #-8] 1003c: e0823003 add r3, r2, r3 10040: e50b3008 str r3, [fp, #-8] /home/manuel/SDL-1.2.15/./src/events/SDL_events.c:248 10044: eb000c97 bl 132a8 <SDL_MouseInit> 10048: e1a03000 mov r3, r0 1004c: e51b2008 ldr r2, [fp, #-8] 10050: e0823003 add r3, r2, r3 10054: e50b3008 str r3, [fp, #-8] /home/manuel/SDL-1.2.15/./src/events/SDL_events.c:249 10058: eb000f76 bl 13e38 <SDL_QuitInit> 1005c: e1a03000 mov r3, r0 10060: e51b2008 ldr r2, [fp, #-8] 10064: e0823003 add r3, r2, r3 10068: e50b3008 str r3, [fp, #-8] /home/manuel/SDL-1.2.15/./src/events/SDL_events.c:250 1006c: e51b3008 ldr r3, [fp, #-8] 10070: e3530000 cmp r3, #0 10074: aa000001 bge 10080 <SDL_StartEventLoop+0x104> /home/manuel/SDL-1.2.15/./src/events/SDL_events.c:252 10078: e3e03000 mvn r3, #0 1007c: ea000008 b 100a4 <SDL_StartEventLoop+0x128> /home/manuel/SDL-1.2.15/./src/events/SDL_events.c:256 10080: e51b0010 ldr r0, [fp, #-16] 10084: ebffff13 bl fcd8 <SDL_StartEventThread> 10088: e1a03000 mov r3, r0 1008c: e3530000 cmp r3, #0 10090: aa000002 bge 100a0 <SDL_StartEventLoop+0x124> /home/manuel/SDL-1.2.15/./src/events/SDL_events.c:257 10094: ebffffa1 bl ff20 <SDL_StopEventLoop> /home/manuel/SDL-1.2.15/./src/events/SDL_events.c:258 10098: e3e03000 mvn r3, #0 1009c: ea000000 b 100a4 <SDL_StartEventLoop+0x128> /home/manuel/SDL-1.2.15/./src/events/SDL_events.c:260 100a0: e3a03000 mov r3, #0 /home/manuel/SDL-1.2.15/./src/events/SDL_events.c:261 100a4: e1a00003 mov r0, r3 100a8: e24bd004 sub sp, fp, #4 100ac: e8bd8800 pop {fp, pc} 100b0: 0005aa64 .word 0x0005aa64 100b4: 00059c38 .word 0x00059c38 100b8: 00059c1c .word 0x00059c1c 100bc: 0007d8ac .word 0x0007d8ac 100c0: 00059bf8 .word 0x00059bf8 100c4: 00059be8 .word 0x00059be8 100c8: 00059bd8 .word 0x00059bd8 100cc: 0007d868 .word 0x0007d868 000100d0 <SDL_AddEvent>: SDL_AddEvent(): /home/manuel/SDL-1.2.15/./src/events/SDL_events.c:266 100d0: e92d0810 push {r4, fp} 100d4: e28db004 add fp, sp, #4 100d8: e24dd018 sub sp, sp, #24 [/code] It's worth mentioning that I can single-step all right in this same code with the same compilation process on my Lubuntu 12.04 machine (X86_64). So there must be something Gentoo (or ARM) related causing this strange behaviour. Here are the versions of GCC and GDB I'm using: [code] GNU gdb (Gentoo 7.4.1 p2) 7.4.1 This GDB was configured as "armv7a-hardfloat-linux-gnueabi". [code] [code] manuel@panda ~/parallax-2 $ gcc -v Using built-in specs. COLLECT_GCC=/usr/armv7a-hardfloat-linux-gnueabi/gcc-bin/4.6.3/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7a-hardfloat-linux-gnueabi/4.6.3/lto-wrapper Target: armv7a-hardfloat-linux-gnueabi Configured with: /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure --prefix=/usr --bindir=/usr/armv7a-hardfloat-linux-gnueabi/gcc-bin/4.6.3 --includedir=/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.6.3/include --datadir=/usr/share/gcc-data/armv7a-hardfloat-linux-gnueabi/4.6.3 --mandir=/usr/share/gcc-data/armv7a-hardfloat-linux-gnueabi/4.6.3/man --infodir=/usr/share/gcc-data/armv7a-hardfloat-linux-gnueabi/4.6.3/info --with-gxx-include-dir=/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.6.3/include/g++-v4 --host=armv7a-hardfloat-linux-gnueabi --build=armv7a-hardfloat-linux-gnueabi --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-lto --with-float=hard --disable-nls --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/armv7a-hardfloat-linux-gnueabi/4.6.3/python --enable-checking=release --disable-libgcj --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.3 p1.5, pie-0.5.2' Thread model: posix gcc version 4.6.3 (Gentoo 4.6.3 p1.5, pie-0.5.2) [/code] -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
next reply other threads:[~2012-08-12 16:24 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-08-12 16:24 redwindwanderer at gmail dot com [this message] 2012-11-28 17:10 ` [Bug gdb/14458] " tromey at redhat dot com 2012-11-28 17:59 ` palves at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-14458-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).