[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Oded Hanson]

Hello All.


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
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

?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140228/02fbe1da/attachment.html>

[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Baruch Siach]

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 -

[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Baruch Siach]

Hi Oded,

Please keep the list on CC so that everyone may benefit from your experience.

On Sun, Mar 02, 2014 at 05:20:25AM +0000, Oded Hanson wrote:
> Thanks Baruch
> 
> Why do you say I am using host linker ? Where can you see that ?

No. Your host GDB is using your host dynamic linker (and libraries) instead of 
your target's. Your host GDB does not have direct access to your target 
libraries. The host GDB relies on having access to these files on your host. 
As you can see from the GDB output you provided, GDB loads 
/lib64/ld-linux-x86-64.so.2 which is the dynamic linker of your host, and is 
apparently incompatible with your target's one.

> I have rechecked the eclipse plugin for buildroot,? and it seems to be 
> configured correctly to use the linker from the buildroot.? Also,? the gdb 
> debugger is called from the buildroot path.? The segmentation fault occurs 
> when I run the gdb both manually and also from the eclipse using the plugin 
> setup.
>
> I have more information now.? If I select the external toolchain with a 
> precomplied toolchain instead of the internal glibc toolchain,? then every 
> thing seems to work fine.? So I guess it might have to do specifically with 
> the internal glibc toolchain. I understand its still experimental?

The external toolchain may bundle a dynamic linker and C library that are 
compatible enough with you host's to makes your HelloWorld run correctly. If 
you try to actually step into the code of the dynamic linker and C library 
you'll probably hit mismatch problems.

baruch

> On Mar 2, 2014 6:28 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> > 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 -

[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Oded Hanson]

Sorry.  Missed the reply all :)

Baruch,  is there something in my logs which make you see that im using wrong linker ? Because im looking at the compilation and linking parameters in eclipse and they seem to be pointing to the right path.

Why are you so certain im using the host linker ?

Oded

On Mar 2, 2014 9:07 AM, Baruch Siach <baruch@tkos.co.il> wrote:
Hi Oded,

Please keep the list on CC so that everyone may benefit from your experience.

On Sun, Mar 02, 2014 at 05:20:25AM +0000, Oded Hanson wrote:
> Thanks Baruch
>
> Why do you say I am using host linker ? Where can you see that ?

No. Your host GDB is using your host dynamic linker (and libraries) instead of
your target's. Your host GDB does not have direct access to your target
libraries. The host GDB relies on having access to these files on your host.
As you can see from the GDB output you provided, GDB loads
/lib64/ld-linux-x86-64.so.2 which is the dynamic linker of your host, and is
apparently incompatible with your target's one.

> I have rechecked the eclipse plugin for buildroot,  and it seems to be
> configured correctly to use the linker from the buildroot.  Also,  the gdb
> debugger is called from the buildroot path.  The segmentation fault occurs
> when I run the gdb both manually and also from the eclipse using the plugin
> setup.
>
> I have more information now.  If I select the external toolchain with a
> precomplied toolchain instead of the internal glibc toolchain,  then every
> thing seems to work fine.  So I guess it might have to do specifically with
> the internal glibc toolchain. I understand its still experimental?

The external toolchain may bundle a dynamic linker and C library that are
compatible enough with you host's to makes your HelloWorld run correctly. If
you try to actually step into the code of the dynamic linker and C library
you'll probably hit mismatch problems.

baruch

> On Mar 2, 2014 6:28 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> > 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 -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140302/ff6e8549/attachment.html>

[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Oded Hanson]

I missed your answer about the GDB.

How can I force GDB to use my cross compiler libs instead?

The logs you see are from my manually using GDB,  which indeed might have not been configured to use the cross compiler libs,  however,  I get the same problem when using the debugger from eclipse,  using the buildroot plugin , which does indeed use the libraries from the cross compiler (at least it should,  how can I verify this? )

Thanks so much

Oded

On Mar 2, 2014 9:07 AM, Baruch Siach <baruch@tkos.co.il> wrote:
Hi Oded,

Please keep the list on CC so that everyone may benefit from your experience.

On Sun, Mar 02, 2014 at 05:20:25AM +0000, Oded Hanson wrote:
> Thanks Baruch
>
> Why do you say I am using host linker ? Where can you see that ?

No. Your host GDB is using your host dynamic linker (and libraries) instead of
your target's. Your host GDB does not have direct access to your target
libraries. The host GDB relies on having access to these files on your host.
As you can see from the GDB output you provided, GDB loads
/lib64/ld-linux-x86-64.so.2 which is the dynamic linker of your host, and is
apparently incompatible with your target's one.

> I have rechecked the eclipse plugin for buildroot,  and it seems to be
> configured correctly to use the linker from the buildroot.  Also,  the gdb
> debugger is called from the buildroot path.  The segmentation fault occurs
> when I run the gdb both manually and also from the eclipse using the plugin
> setup.
>
> I have more information now.  If I select the external toolchain with a
> precomplied toolchain instead of the internal glibc toolchain,  then every
> thing seems to work fine.  So I guess it might have to do specifically with
> the internal glibc toolchain. I understand its still experimental?

The external toolchain may bundle a dynamic linker and C library that are
compatible enough with you host's to makes your HelloWorld run correctly. If
you try to actually step into the code of the dynamic linker and C library
you'll probably hit mismatch problems.

baruch

> On Mar 2, 2014 6:28 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> > 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 -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140302/72a5fbd1/attachment.html>

[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Baruch Siach]

Hi Oded,

On Sun, Mar 02, 2014 at 07:27:36AM +0000, Oded Hanson wrote:
> I missed your answer about the GDB.
> 
> How can I force GDB to use my cross compiler libs instead?
> 
> The logs you see are from my manually using GDB,  which indeed might have 
> not been configured to use the cross compiler libs,  however,  I get the 
> same problem when using the debugger from eclipse,  using the buildroot 
> plugin , which does indeed use the libraries from the cross compiler (at 
> least it should,  how can I verify this? )

I'm not familiar with the Eclipse plugin so I can't comment on that. As to 
command line invocation of GDB you can change the sysroot of GDB as I said in 
my original response with:

(gdb) set sysroot /home/oded/Buildroot/buildroot-2013.11/output/staging

GDB uses sysroot to locate your target dynamic linker and libraries.

baruch

> On Mar 2, 2014 9:07 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> Please keep the list on CC so that everyone may benefit from your 
> experience.
> 
> On Sun, Mar 02, 2014 at 05:20:25AM +0000, Oded Hanson wrote:
> > Thanks Baruch
> >
> > Why do you say I am using host linker ? Where can you see that ?
> 
> No. Your host GDB is using your host dynamic linker (and libraries) instead of
> your target's. Your host GDB does not have direct access to your target
> libraries. The host GDB relies on having access to these files on your host.
> As you can see from the GDB output you provided, GDB loads
> /lib64/ld-linux-x86-64.so.2 which is the dynamic linker of your host, and is
> apparently incompatible with your target's one.
> 
> > I have rechecked the eclipse plugin for buildroot,  and it seems to be
> > configured correctly to use the linker from the buildroot.  Also,  the gdb
> > debugger is called from the buildroot path.  The segmentation fault occurs
> > when I run the gdb both manually and also from the eclipse using the plugin
> > setup.
> >
> > I have more information now.  If I select the external toolchain with a
> > precomplied toolchain instead of the internal glibc toolchain,  then every
> > thing seems to work fine.  So I guess it might have to do specifically with
> > the internal glibc toolchain. I understand its still experimental?
> 
> The external toolchain may bundle a dynamic linker and C library that are
> compatible enough with you host's to makes your HelloWorld run correctly. If
> you try to actually step into the code of the dynamic linker and C library
> you'll probably hit mismatch problems.
> 
> baruch
> 
> > On Mar 2, 2014 6:28 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> > > 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 -

-- 
     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 -

[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Oded Hanson]

OK... After 1 hour of rebuilding my system back with the internal GLIBC toolchain I can say...

Thanks !!! :)

Its working. Now I just need to see how to make the eclipse plugin run the set sysroot command 

Oded

-----Original Message-----
From: Baruch Siach [mailto:baruch at tkos.co.il] 
Sent: Sunday, March 02, 2014 11:12 AM
To: Oded Hanson
Cc: buildroot at busybox.net
Subject: Re: [Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

Hi Oded,

On Sun, Mar 02, 2014 at 07:27:36AM +0000, Oded Hanson wrote:
> I missed your answer about the GDB.
> 
> How can I force GDB to use my cross compiler libs instead?
> 
> The logs you see are from my manually using GDB,  which indeed might 
> have not been configured to use the cross compiler libs,  however,  I 
> get the same problem when using the debugger from eclipse,  using the 
> buildroot plugin , which does indeed use the libraries from the cross 
> compiler (at least it should,  how can I verify this? )

I'm not familiar with the Eclipse plugin so I can't comment on that. As to command line invocation of GDB you can change the sysroot of GDB as I said in my original response with:

(gdb) set sysroot /home/oded/Buildroot/buildroot-2013.11/output/staging

GDB uses sysroot to locate your target dynamic linker and libraries.

baruch

> On Mar 2, 2014 9:07 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> Please keep the list on CC so that everyone may benefit from your 
> experience.
> 
> On Sun, Mar 02, 2014 at 05:20:25AM +0000, Oded Hanson wrote:
> > Thanks Baruch
> >
> > Why do you say I am using host linker ? Where can you see that ?
> 
> No. Your host GDB is using your host dynamic linker (and libraries) 
> instead of your target's. Your host GDB does not have direct access to 
> your target libraries. The host GDB relies on having access to these files on your host.
> As you can see from the GDB output you provided, GDB loads
> /lib64/ld-linux-x86-64.so.2 which is the dynamic linker of your host, 
> and is apparently incompatible with your target's one.
> 
> > I have rechecked the eclipse plugin for buildroot,  and it seems to 
> > be configured correctly to use the linker from the buildroot.  Also,  
> > the gdb debugger is called from the buildroot path.  The 
> > segmentation fault occurs when I run the gdb both manually and also 
> > from the eclipse using the plugin setup.
> >
> > I have more information now.  If I select the external toolchain 
> > with a precomplied toolchain instead of the internal glibc 
> > toolchain,  then every thing seems to work fine.  So I guess it 
> > might have to do specifically with the internal glibc toolchain. I understand its still experimental?
> 
> The external toolchain may bundle a dynamic linker and C library that 
> are compatible enough with you host's to makes your HelloWorld run 
> correctly. If you try to actually step into the code of the dynamic 
> linker and C library you'll probably hit mismatch problems.
> 
> baruch
> 
> > On Mar 2, 2014 6:28 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> > > 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_6
> > > > 4-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 -

-- 
     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 -

[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Baruch Siach]

Hi Oded,

On Sun, Mar 02, 2014 at 12:06:35PM +0000, Oded Hanson wrote:
> OK... After 1 hour of rebuilding my system back with the internal GLIBC 
> toolchain I can say...
> 
> Thanks !!! :)

Good to hear. I just want to note again that for correct GDB operation, 
setting sysroot is needed for external toolchains as well.

baruch

> Its working. Now I just need to see how to make the eclipse plugin run the 
> set sysroot command 
> 
> -----Original Message-----
> From: Baruch Siach [mailto:baruch at tkos.co.il] 
> Sent: Sunday, March 02, 2014 11:12 AM
> To: Oded Hanson
> Cc: buildroot at busybox.net
> Subject: Re: [Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer
> 
> On Sun, Mar 02, 2014 at 07:27:36AM +0000, Oded Hanson wrote:
> > I missed your answer about the GDB.
> > 
> > How can I force GDB to use my cross compiler libs instead?
> > 
> > The logs you see are from my manually using GDB,  which indeed might 
> > have not been configured to use the cross compiler libs,  however,  I 
> > get the same problem when using the debugger from eclipse,  using the 
> > buildroot plugin , which does indeed use the libraries from the cross 
> > compiler (at least it should,  how can I verify this? )
> 
> I'm not familiar with the Eclipse plugin so I can't comment on that. As to 
> command line invocation of GDB you can change the sysroot of GDB as I said 
> in my original response with:
> 
> (gdb) set sysroot /home/oded/Buildroot/buildroot-2013.11/output/staging
> 
> GDB uses sysroot to locate your target dynamic linker and libraries.
> 
> baruch

-- 
     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 -

[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Oded Hanson]

Sure I understand that.

I just prefer to used the internal tool chain if possible.

Oded

On Mar 2, 2014 2:24 PM, Baruch Siach <baruch@tkos.co.il> wrote:
Hi Oded,

On Sun, Mar 02, 2014 at 12:06:35PM +0000, Oded Hanson wrote:
> OK... After 1 hour of rebuilding my system back with the internal GLIBC
> toolchain I can say...
>
> Thanks !!! :)

Good to hear. I just want to note again that for correct GDB operation,
setting sysroot is needed for external toolchains as well.

baruch

> Its working. Now I just need to see how to make the eclipse plugin run the
> set sysroot command
>
> -----Original Message-----
> From: Baruch Siach [mailto:baruch at tkos.co.il]
> Sent: Sunday, March 02, 2014 11:12 AM
> To: Oded Hanson
> Cc: buildroot at busybox.net
> Subject: Re: [Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer
>
> On Sun, Mar 02, 2014 at 07:27:36AM +0000, Oded Hanson wrote:
> > I missed your answer about the GDB.
> >
> > How can I force GDB to use my cross compiler libs instead?
> >
> > The logs you see are from my manually using GDB,  which indeed might
> > have not been configured to use the cross compiler libs,  however,  I
> > get the same problem when using the debugger from eclipse,  using the
> > buildroot plugin , which does indeed use the libraries from the cross
> > compiler (at least it should,  how can I verify this? )
>
> I'm not familiar with the Eclipse plugin so I can't comment on that. As to
> command line invocation of GDB you can change the sysroot of GDB as I said
> in my original response with:
>
> (gdb) set sysroot /home/oded/Buildroot/buildroot-2013.11/output/staging
>
> GDB uses sysroot to locate your target dynamic linker and libraries.
>
> baruch

--
     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 -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140302/87970604/attachment.html>

[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Oded Hanson]

For the completeness of the answer, I will add, that in eclipse plugin you can set the GDB command file. Pointing to a file with the set sysroot command in it, solves the issue also in eclipse and I can debug now from eclipse.

I guess this should be fixed in the eclipse plugin setup.

Oded

-----Original Message-----
From: Baruch Siach [mailto:baruch at tkos.co.il] 
Sent: Sunday, March 02, 2014 2:24 PM
To: Oded Hanson
Cc: buildroot at busybox.net
Subject: Re: [Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

Hi Oded,

On Sun, Mar 02, 2014 at 12:06:35PM +0000, Oded Hanson wrote:
> OK... After 1 hour of rebuilding my system back with the internal 
> GLIBC toolchain I can say...
> 
> Thanks !!! :)

Good to hear. I just want to note again that for correct GDB operation, setting sysroot is needed for external toolchains as well.

baruch

> Its working. Now I just need to see how to make the eclipse plugin run 
> the set sysroot command
> 
> -----Original Message-----
> From: Baruch Siach [mailto:baruch at tkos.co.il]
> Sent: Sunday, March 02, 2014 11:12 AM
> To: Oded Hanson
> Cc: buildroot at busybox.net
> Subject: Re: [Buildroot] Segmentation fault while trying to remote 
> debug with GDB and GDBServer
> 
> On Sun, Mar 02, 2014 at 07:27:36AM +0000, Oded Hanson wrote:
> > I missed your answer about the GDB.
> > 
> > How can I force GDB to use my cross compiler libs instead?
> > 
> > The logs you see are from my manually using GDB,  which indeed might 
> > have not been configured to use the cross compiler libs,  however,  
> > I get the same problem when using the debugger from eclipse,  using 
> > the buildroot plugin , which does indeed use the libraries from the 
> > cross compiler (at least it should,  how can I verify this? )
> 
> I'm not familiar with the Eclipse plugin so I can't comment on that. 
> As to command line invocation of GDB you can change the sysroot of GDB 
> as I said in my original response with:
> 
> (gdb) set sysroot 
> /home/oded/Buildroot/buildroot-2013.11/output/staging
> 
> GDB uses sysroot to locate your target dynamic linker and libraries.
> 
> baruch

-- 
     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 -

[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Thomas Petazzoni]

Dear Oded Hanson,

(Adding M?lanie Bats in Cc, since she is responsible for the Eclipse
plugin development)

On Sun, 2 Mar 2014 12:44:23 +0000, Oded Hanson wrote:

> For the completeness of the answer, I will add, that in eclipse plugin you can set the GDB command file. Pointing to a file with the set sysroot command in it, solves the issue also in eclipse and I can debug now from eclipse.
> 
> I guess this should be fixed in the eclipse plugin setup.

The Eclipse plugin does set the solib-path (see
https://github.com/mbats/eclipse-buildroot-toolchain-plugin/blob/master/org.buildroot.cdt.toolchain/src/org/buildroot/cdt/toolchain/BuildrootLaunchConfigurationTabGroup.java#L70),
but that is apparently insufficient for gdb to find the correct dynamic
linker, especially when the host and target architectures are identical.

Since there is apparently no way in Eclipse to set a gdb sysroot, I
believe the only solution is for the Eclipse plugin to generate a
simple gdbinit file:

set sysroot /path/to/staging/directory

and then instruct Eclipse to use it.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Oded Hanson]

Yes.  I believe thats the correct solution,  and thats what I did manually.

Oded

On Mar 2, 2014 6:10 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
Dear Oded Hanson,

(Adding M?lanie Bats in Cc, since she is responsible for the Eclipse
plugin development)

On Sun, 2 Mar 2014 12:44:23 +0000, Oded Hanson wrote:

> For the completeness of the answer, I will add, that in eclipse plugin you can set the GDB command file. Pointing to a file with the set sysroot command in it, solves the issue also in eclipse and I can debug now from eclipse.
>
> I guess this should be fixed in the eclipse plugin setup.

The Eclipse plugin does set the solib-path (see
https://github.com/mbats/eclipse-buildroot-toolchain-plugin/blob/master/org.buildroot.cdt.toolchain/src/org/buildroot/cdt/toolchain/BuildrootLaunchConfigurationTabGroup.java#L70),
but that is apparently insufficient for gdb to find the correct dynamic
linker, especially when the host and target architectures are identical.

Since there is apparently no way in Eclipse to set a gdb sysroot, I
believe the only solution is for the Eclipse plugin to generate a
simple gdbinit file:

set sysroot /path/to/staging/directory

and then instruct Eclipse to use it.

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140302/00499559/attachment.html>

[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Thomas Petazzoni]

Hello,

On Sun, 2 Mar 2014 17:10:08 +0100, Thomas Petazzoni wrote:

> The Eclipse plugin does set the solib-path (see
> https://github.com/mbats/eclipse-buildroot-toolchain-plugin/blob/master/org.buildroot.cdt.toolchain/src/org/buildroot/cdt/toolchain/BuildrootLaunchConfigurationTabGroup.java#L70),
> but that is apparently insufficient for gdb to find the correct dynamic
> linker, especially when the host and target architectures are identical.
> 
> Since there is apparently no way in Eclipse to set a gdb sysroot, I
> believe the only solution is for the Eclipse plugin to generate a
> simple gdbinit file:
> 
> set sysroot /path/to/staging/directory
> 
> and then instruct Eclipse to use it.

Or now that I think of it, maybe Buildroot should itself generate this
gdbinit file. It may be useful even for users not using Eclipse.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Arnout Vandecappelle]

On 02/03/14 17:20, Thomas Petazzoni wrote:
> Hello,
> 
> On Sun, 2 Mar 2014 17:10:08 +0100, Thomas Petazzoni wrote:
> 
>> The Eclipse plugin does set the solib-path (see
>> https://github.com/mbats/eclipse-buildroot-toolchain-plugin/blob/master/org.buildroot.cdt.toolchain/src/org/buildroot/cdt/toolchain/BuildrootLaunchConfigurationTabGroup.java#L70),
>> but that is apparently insufficient for gdb to find the correct dynamic
>> linker, especially when the host and target architectures are identical.
>>
>> Since there is apparently no way in Eclipse to set a gdb sysroot, I
>> believe the only solution is for the Eclipse plugin to generate a
>> simple gdbinit file:
>>
>> set sysroot /path/to/staging/directory
>>
>> and then instruct Eclipse to use it.
> 
> Or now that I think of it, maybe Buildroot should itself generate this
> gdbinit file. It may be useful even for users not using Eclipse.

 Even better: buildroot should generate a wrapper (yet another one!) that
passes -ex 'set sysroot ...' when calling cross-gdb.

 Can someone add that to the todo list on the wiki? (I'm currently offline.)

 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Wed, 05 Mar 2014 07:42:04 +0100, Arnout Vandecappelle wrote:

> > On Sun, 2 Mar 2014 17:10:08 +0100, Thomas Petazzoni wrote:
> > 
> >> The Eclipse plugin does set the solib-path (see
> >> https://github.com/mbats/eclipse-buildroot-toolchain-plugin/blob/master/org.buildroot.cdt.toolchain/src/org/buildroot/cdt/toolchain/BuildrootLaunchConfigurationTabGroup.java#L70),
> >> but that is apparently insufficient for gdb to find the correct dynamic
> >> linker, especially when the host and target architectures are identical.
> >>
> >> Since there is apparently no way in Eclipse to set a gdb sysroot, I
> >> believe the only solution is for the Eclipse plugin to generate a
> >> simple gdbinit file:
> >>
> >> set sysroot /path/to/staging/directory
> >>
> >> and then instruct Eclipse to use it.
> > 
> > Or now that I think of it, maybe Buildroot should itself generate this
> > gdbinit file. It may be useful even for users not using Eclipse.
> 
>  Even better: buildroot should generate a wrapper (yet another one!) that
> passes -ex 'set sysroot ...' when calling cross-gdb.

Except that as of today, we don't generate any wrapper for the case of
the internal toolchain, while this particular "set sysroot ..." thing
is useful for both internal and external toolchains.

Do we want to switch to use wrappers for the internal toolchain as
well? This would mean that it can no longer be simply installed into
$(HOST_DIR)/usr. To be honest, I'm not sure we want to do make this
change.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Oded Hanson]

What about the include path when compiling from eclipse ? Any chance its using my host include files ?

I can see that its using the cross compiler for sure,  but don't see where the include path is set.

Oded

On Mar 2, 2014 6:10 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
Dear Oded Hanson,

(Adding M?lanie Bats in Cc, since she is responsible for the Eclipse
plugin development)

On Sun, 2 Mar 2014 12:44:23 +0000, Oded Hanson wrote:

> For the completeness of the answer, I will add, that in eclipse plugin you can set the GDB command file. Pointing to a file with the set sysroot command in it, solves the issue also in eclipse and I can debug now from eclipse.
>
> I guess this should be fixed in the eclipse plugin setup.

The Eclipse plugin does set the solib-path (see
https://github.com/mbats/eclipse-buildroot-toolchain-plugin/blob/master/org.buildroot.cdt.toolchain/src/org/buildroot/cdt/toolchain/BuildrootLaunchConfigurationTabGroup.java#L70),
but that is apparently insufficient for gdb to find the correct dynamic
linker, especially when the host and target architectures are identical.

Since there is apparently no way in Eclipse to set a gdb sysroot, I
believe the only solution is for the Eclipse plugin to generate a
simple gdbinit file:

set sysroot /path/to/staging/directory

and then instruct Eclipse to use it.

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140302/b833bd83/attachment.html>

[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Baruch Siach]

Hi Oded,

On Sun, Mar 02, 2014 at 04:49:03PM +0000, Oded Hanson wrote:
> What about the include path when compiling from eclipse ? Any chance its 
> using my host include files ?

This should not happen.

> I can see that its using the cross compiler for sure,  but don't see where 
> the include path is set.

The cross gcc uses its sysroot as logical root directory for headers and 
libraries. Buildroot sets gcc sysroot to the staging directory. For the 
internal toolchain sysroot is defined at build time (see package/gcc/gcc.mk). 
For external toolchain sysroot is set on gcc command line by the external 
toolchain wrapper (see toolchain/toolchain-external/ext-toolchain-wrapper.c).

baruch

> On Mar 2, 2014 6:10 PM, Thomas Petazzoni 
> <thomas.petazzoni@free-electrons.com> wrote:
> Dear Oded Hanson,
> 
> (Adding M?lanie Bats in Cc, since she is responsible for the Eclipse
> plugin development)
> 
> On Sun, 2 Mar 2014 12:44:23 +0000, Oded Hanson wrote:
> 
> > For the completeness of the answer, I will add, that in eclipse plugin you 
> > can set the GDB command file. Pointing to a file with the set sysroot 
> > command in it, solves the issue also in eclipse and I can debug now from 
> > eclipse.
> >
> > I guess this should be fixed in the eclipse plugin setup.
> 
> The Eclipse plugin does set the solib-path (see
> https://github.com/mbats/eclipse-buildroot-toolchain-plugin/blob/master/org.buildroot.cdt.toolchain/src/org/buildroot/cdt/toolchain/BuildrootLaunchConfigurationTabGroup.java#L70),
> but that is apparently insufficient for gdb to find the correct dynamic
> linker, especially when the host and target architectures are identical.
> 
> Since there is apparently no way in Eclipse to set a gdb sysroot, I
> believe the only solution is for the Eclipse plugin to generate a
> simple gdbinit file:
> 
> set sysroot /path/to/staging/directory
> 
> and then instruct Eclipse to use it.
> 
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

-- 
     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 -

[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Thomas Petazzoni]

Dear Baruch Siach,

On Sun, 2 Mar 2014 21:48:33 +0200, Baruch Siach wrote:

> On Sun, Mar 02, 2014 at 04:49:03PM +0000, Oded Hanson wrote:
> > What about the include path when compiling from eclipse ? Any
> > chance its using my host include files ?
> 
> This should not happen.

Indeed. Having the cross-compiler include host header files would be
horribly wrong.

> > I can see that its using the cross compiler for sure,  but don't
> > see where the include path is set.
> 
> The cross gcc uses its sysroot as logical root directory for headers
> and libraries. Buildroot sets gcc sysroot to the staging directory.
> For the internal toolchain sysroot is defined at build time (see
> package/gcc/gcc.mk). For external toolchain sysroot is set on gcc
> command line by the external toolchain wrapper (see
> toolchain/toolchain-external/ext-toolchain-wrapper.c).

Correct. Unless there is a bug, the Eclipse plug-in simply calls the
Buildroot cross-compiler, and the Buildroot cross-compiler already
properly looks in the staging directory (which is its sysroot) for
headers and libraries. I remember testing the Eclipse plugin with
several libraries integrated in the toolchain sysroot, with success.

Oded, can you be more specific about the problems you have seen?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Segmentation fault while trying to remote debug with GDB and GDBServer

[Oded Hanson]

Hi Thomas.

Sorry if I confused you.  I have seen no problem - the debugger problem has been solved.  I just wanted to make sure I am not experiencing (without even knowing,  since my host and target environment are the same)  similar issues during the compilation stages,  since I dont see any where where include paths are set.  But your and Baruch explanations regarding sysroot (never heard about this before,  where I come from,  I'm used to setting include and lib paths)  answer my question.

Thanks a lot for the support - much appreciated .

Oded

On Mar 2, 2014 10:03 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
Dear Baruch Siach,

On Sun, 2 Mar 2014 21:48:33 +0200, Baruch Siach wrote:

> On Sun, Mar 02, 2014 at 04:49:03PM +0000, Oded Hanson wrote:
> > What about the include path when compiling from eclipse ? Any
> > chance its using my host include files ?
>
> This should not happen.

Indeed. Having the cross-compiler include host header files would be
horribly wrong.

> > I can see that its using the cross compiler for sure,  but don't
> > see where the include path is set.
>
> The cross gcc uses its sysroot as logical root directory for headers
> and libraries. Buildroot sets gcc sysroot to the staging directory.
> For the internal toolchain sysroot is defined at build time (see
> package/gcc/gcc.mk). For external toolchain sysroot is set on gcc
> command line by the external toolchain wrapper (see
> toolchain/toolchain-external/ext-toolchain-wrapper.c).

Correct. Unless there is a bug, the Eclipse plug-in simply calls the
Buildroot cross-compiler, and the Buildroot cross-compiler already
properly looks in the staging directory (which is its sysroot) for
headers and libraries. I remember testing the Eclipse plugin with
several libraries integrated in the toolchain sysroot, with success.

Oded, can you be more specific about the problems you have seen?

Thanks,

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140303/ec9aa72c/attachment.html>