From mboxrd@z Thu Jan 1 00:00:00 1970 From: Baruch Siach Date: Sun, 2 Mar 2014 06:27:55 +0200 Subject: [Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer In-Reply-To: <32f685ebc5be4300a826161c8be8d2fd@DBXPR07MB142.eurprd07.prod.outlook.com> References: <32f685ebc5be4300a826161c8be8d2fd@DBXPR07MB142.eurprd07.prod.outlook.com> Message-ID: <20140302042755.GA3874@tarshish> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net Hi Oded, On Fri, Feb 28, 2014 at 03:58:49PM +0000, Oded Hanson wrote: > I have built a target based on a x86_64 architecture. I am booting it for > testing on virtualbox (but it also boots with no problem on my target). I am > using the buildroot's internal toolchain and the glibc C library (not uclibc > !!). I have tryed few GCC compiler versions and few GDB debugger versions, > all resulting with the same issues. Currently using kernel 3.12.x, GCC 4.7.x > and GDB 7.4.x. > > I have compiled a simple helloworld app, using the eclipse plugin for > buildroot. I have made sure its using the GCC generated by buildroot. > > When I run the helloworld application on the target machine, it works fine > as expected. However, when I try to remote debug it, it crashes with a > segmentation fault right at the start before it even reaches the main. > > I have performed the same action on my host (since its also x86_64 I can do > that :) ) and there, no segmentation fault occurs. > > I have attached the logs from both the gdbserver (run on the target machine) > and the gdb (run on the host), I really hope someone will have an idea, > because I have searched the entire internet (literally), and unfortunately I > have no clue whats going wrong here: > > gdb (host): > > oded at oded-VirtualBox:~/workspace/HelloWorld/debug$ /home/oded/Buildroot/buildroot-2013.11/output/host/usr/bin/x86_64-buildroot-linux-gnu-gdb HelloWorld > GNU gdb (GDB) 7.4.1 > Copyright (C) 2012 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > 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 "--host=x86_64-unknown-linux-gnu --target=x86_64-buildroot-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /home/oded/workspace/HelloWorld/debug/HelloWorld...done. > (gdb) target remote 192.168.0.67:2235 > Remote debugging using 192.168.0.67:2235 > Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. > Loaded symbols for /lib64/ld-linux-x86-64.so.2 This is wrong. You are using the dynamic linker (and libraries) of your host. This doesn't emit an error message just because your host and target architectures are identical (x86-64). Try setting sysroot to your buildroot staging directory: (gdb) set sysroot /home/oded/Buildroot/buildroot-2013.11/output/staging baruch > 0x00007ffff7dde2c0 in ?? () from /lib64/ld-linux-x86-64.so.2 > (gdb) continue > Continuing. > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff7ded14f in ?? () from /lib64/ld-linux-x86-64.so.2 > (gdb) > > > gdbserver (target): > > # ./test > Hello World# > # gdbserver --debug :2235 ./test > my_waitpid (954, 0x0) > my_waitpid (954, 0x0): status(137f), 954 > my_waitpid (954, 0x0) > my_waitpid (954, 0x0): status(1057f), 954 > my_waitpid (955, 0x0) > my_waitpid (955, 0x0): status(137f), 955 > my_waitpid (955, 0x0) > my_waitpid (955, 0x0): status(9), 955 > my_waitpid (954, 0x0) > my_waitpid (954, 0x0): status(117f), 954 > my_waitpid (954, 0x0) > my_waitpid (954, 0x0): status(9), 954 > new_argv[0] = "./test" > Process ./test created; pid = 956 > linux_wait: [Process 956] > linux_wait_for_lwp: > my_waitpid (-1, 0x40000000) > blocking > sigchld_handler > my_waitpid (-1, 0x1): status(57f), 956 > Got an event from 956 (57f) > pc is 0x7ffff7dde2c0 > stop pc is 0x7ffff7dde2bf > linux_wait_for_lwp: pc is 0x7ffff7dde2c0 > Hit a non-gdbserver trap event. > wait_for_sigstop: LWP 956 already stopped > Checking whether LWP 956 needs to move out of the jump pad...no > linux_wait ret = LWP 956.956, 1, 5 > Listening on port 2235 > handling possible accept event > Remote debugging from host 192.168.0.176 > linux_async (0), previous=0 > handling possible serial event > handling possible serial event > handling possible serial event > handling possible serial event > handling possible serial event > handling possible serial event > handling possible serial event > handling possible serial event > linux_async (0), previous=0 > handling possible serial event > wait_for_sigstop: LWP 956 already stopped > Checking whether LWP 956 needs to move out of the jump pad...no > Writing resume reply for LWP 956.956:1 > > handling possible serial event > handling possible serial event > handling possible serial event > handling possible serial event > handling possible serial event > handling possible serial event > handling possible serial event > handling possible serial event > symbol `gdb_agent_gdb_tp_heap_buffer' not found > Trying host libthread_db library: libthread_db.so.1. > Host libthread_db.so.1 resolved to: /lib/libthread_db.so.1. > td_ta_new(): application not linked with libthread > thread_db_load_search returning 0 > handling possible serial event > handling possible serial event > handling possible serial event > handling possible serial event > symbol `gdb_agent_gdb_tp_heap_buffer' not found > Trying host libthread_db library: libthread_db.so.1. > Host libthread_db.so.1 resolved to: /lib/libthread_db.so.1. > td_ta_new(): application not linked with libthread > thread_db_load_search returning 0 > handling possible serial event > handling possible serial event > handling possible serial event > handling possible serial event > symbol `gdb_agent_gdb_tp_heap_buffer' not found > Trying host libthread_db library: libthread_db.so.1. > Host libthread_db.so.1 resolved to: /lib/libthread_db.so.1. > td_ta_new(): application not linked with libthread > thread_db_load_search returning 0 > handling possible serial event > gdbserver/tracepoint: Returning trace status as 0, stop reason tnotrun > handling possible serial event > gdbserver/tracepoint: Returning first trace state variable definition > handling possible serial event > gdbserver/tracepoint: Returning first trace state variable definition > handling possible serial event > gdbserver/tracepoint: Returning first tracepoint definition piece > handling possible serial event > gdbserver/tracepoint: Returning trace status as 0, stop reason tnotrun > handling possible serial event > Writing cc to 0x7ffff7ded160 > handling possible serial event > handling possible serial event > handling possible serial event > Need step over [LWP 956]? No > pc is 0x7ffff7dde2c0 > Need step over [LWP 956]? Cancelling, PC was changed. Old stop_pc was 0x7ffff7dde2bf, PC is now 0x7ffff7dde2c0 > Resuming, no pending status or step over needed > resuming LWP 956 > pc is 0x7ffff7dde2c0 > Resuming lwp 956 (continue, signal 0, stop not expected) > resuming from pc 0x7ffff7dde2c0 > linux_wait: [] > linux_wait_for_lwp: > my_waitpid (-1, 0x40000000) > blocking > sigchld_handler > my_waitpid (-1, 0x1): status(b7f), 956 > Got an event from 956 (b7f) > pc is 0x7ffff7ded14f > stop pc is 0x7ffff7ded14f > linux_wait_for_lwp: pc is 0x7ffff7ded14f > Hit a non-gdbserver trap event. > wait_for_sigstop: LWP 956 already stopped > Checking whether LWP 956 needs to move out of the jump pad...no > linux_wait ret = LWP 956.956, 1, 11 > Writing resume reply for LWP 956.956:1 > > handling possible serial event > Writing cd to 0x7ffff7ded160 > handling possible serial event > handling possible serial event > handling possible serial event > > ? -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -