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

["H.J. Lu" <hjl.tools@gmail.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 set breakpoint in x86_linux_process_qsupported. Gdb only stopped
at the first call. The second call was never stopped. It may be a
follow-fork issue.


-- 
H.J.