Re: Fix solib-disc.exp regression with x86 gdbserver

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Sun, Apr 11, 2010 at 7:17 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> On Sunday 11 April 2010 15:04:39, H.J. Lu wrote:
>> How can I debug gdbserver with gdb? I tried and it didn't work.
>
> What doesn't work? ?It Just Works for me:
>
> ?$gdb -q --args ./gdbserver :9999 ~/gdb/tests/threads
> ?Reading symbols from /home/pedro/gdb/gdbserver_tracepoints_step_over_bkpt_pushed/build/gdb/gdbserver/gdbserver...done.
> ?(gdb) start
> ?Temporary breakpoint 1 at 0x40f51f: file ../../../src/gdb/gdbserver/server.c, line 2238.
> ?Starting program: /home/pedro/gdb/gdbserver_tracepoints_step_over_bkpt_pushed/build/gdb/gdbserver/gdbserver :9999 /home/pedro/gdb/tests/threads
>
> ?Temporary breakpoint 1, main (argc=4, argv=0x7fffffffe068) at ../../../src/gdb/gdbserver/server.c:2238
> ?2238 ? ? ?char **next_arg = &argv[1];
> ?(gdb)
>
>
> Attaching works too:
>
> ?$ ./gdbserver :9999 ~/gdb/tests/threads
> ?...
>
> ?$ gdb -p $(pidof gdbserver)
> ?...
>
> It used to be GDB would get confused due to the uses of the clone
> syscall in linux-low.c, and so breakpoints wouldn't work. ?The
> easy workaround was just to comment out the linux_test_for_tracefork
> call (and hardcode linux_supports_tracefork_flag as 1, to get the
> same behaviour you'd get without the hack). ?clone is only used
> on uclinux/nommu, so you shouldn't need the hack anymore on linux.
>
> gdbserver's "--debug" command line switch is also useful (it enables
> all that the internal debug output controlled by `if (debug_threads)').
> "(gdb) monitor set debug 1" has the same effect.

I will git it a try next time when I run into gdbserver problems.

BTW, I followed:

http://sourceware.org/gdb/wiki/TestingGDB#Testing_gdbserver_in_a_native_configuration

I couldn't get dejagnu to find the native-gdbserver board file. I had
to put

set gdbserve_board_dir xxxxx/gdbserver/boards
lappend boards_dir $gdbserve_board_dir

in my ~/.dejagnurc.


-- 
H.J.