Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Baruch Siach <baruch@tkos.co.il>
To: buildroot@busybox.net
Subject: [Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer
Date: Sun, 2 Mar 2014 06:27:55 +0200	[thread overview]
Message-ID: <20140302042755.GA3874@tarshish> (raw)
In-Reply-To: <32f685ebc5be4300a826161c8be8d2fd@DBXPR07MB142.eurprd07.prod.outlook.com>

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 <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 "--host=x86_64-unknown-linux-gnu --target=x86_64-buildroot-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> 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: <all threads>
> 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: [<all threads>]
> linux_wait_for_lwp: <all threads>
> 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 -

  reply	other threads:[~2014-03-02  4:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-28 15:58 [Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer Oded Hanson
2014-03-02  4:27 ` Baruch Siach [this message]
     [not found] <51ef4c3ec6f84eab802c23a14ecb48ae@DBXPR07MB142.eurprd07.prod.outlook.com>
2014-03-02  7:06 ` Baruch Siach
2014-03-02  7:23   ` Oded Hanson
2014-03-02  7:27   ` Oded Hanson
2014-03-02  9:12     ` Baruch Siach
2014-03-02 12:06       ` Oded Hanson
2014-03-02 12:24         ` Baruch Siach
2014-03-02 12:32           ` Oded Hanson
2014-03-02 12:44           ` Oded Hanson
2014-03-02 16:10             ` Thomas Petazzoni
2014-03-02 16:14               ` Oded Hanson
2014-03-02 16:20               ` Thomas Petazzoni
2014-03-05  6:42                 ` Arnout Vandecappelle
2014-03-23 21:07                   ` Thomas Petazzoni
2014-03-02 16:49               ` Oded Hanson
2014-03-02 19:48                 ` Baruch Siach
2014-03-02 20:03                   ` Thomas Petazzoni
2014-03-03  3:42                     ` Oded Hanson

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=20140302042755.GA3874@tarshish \
    --to=baruch@tkos.co.il \
    --cc=buildroot@busybox.net \
    /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: link
Be 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