[uClibc] uclibc gdb and threads

[Andrew de Quincey]

On Saturday 06 Nov 2004 00:16, Andrew de Quincey wrote:
> On Friday 05 Nov 2004 23:50, Ton Truong wrote:
> > OK, my bad.  We have it working on MIPS, not sure about PPC.  Requires
> > latest uClibc snapshot (11/3/04 or later) though.
>
> Interesting. I've just put tracing in the kernel - the kernel is picking up
> on the breakpoints ok - I can see it forcing a SIGTRAP. However,
> gdb/gdbserver are not seeing anything.
>
> Adding more tracing... everywhere :)

Something very weird is going on - or else I'm doing something totally stupid. 
No idea which yet, although I have a strong suspicion it is the latter.

I've added tracing of the remote protocol to gdbserver -
RX means a packet received from gdb, TS a packet sent by gdbserver.

--- I connect to the remote target with target remote ip:port

RX: Hc-1
TX: OK
RX: qC
TX:
RX: qOffsets
TX:
RX: ?
TX: T0501:7ffffb70;40:3000108c;
RX: Hg0
TX: OK
RX: g
TX: 000000007ffffb7000000000000000000000000000000000000000000000000000000000000000000000000000000
RX: mfffffffc,c
TX: E01
RX: mfffffffc,c
TX: E01
RX: m10010904,b0
TX: 00000001000000010000000c1000036c0000000d1000089c000000041000012800000005100002680000000610000
RX: qSymbol::
TX: OK                                                                                           

-- At this point, GDB stops at the _dl_boot function (i think). I type "break main" and then "c"

RX: Z0,10000548,4
TX:
RX: m10000548,4
TX: 38000000
RX: X10000548,0:
TX:
RX: M10000548,4:7d821008
TX: OK

-- here GDB read the contents of 0x10000548 - my breakpoint - and replaces it
with the trap instruction (0x7d821008)

RX: m300018d4,4
TX: 801c005c
RX: M300018d4,4:7d821008
TX: OK

-- here GDB read the contents of 0x300018d4 - an internal breakpoint on the _dl_debug_state function - and replaces it
with the trap instruction (0x7d821008).

RX: vCont?
X: vCont;c;C;s;S
RX: vCont;c

-- this is my continue command. It runs until GDB hits the following breakpoint.

TX: T0501:7ffff4e0;40:300018d4;

-- this is the internal breakpoint on _dl_debug_state being triggered. This is the one I
was seeing from my kernel tracing.

RX: m10000548,4
TX: 7d821008
RX: M10000548,4:38000000
TX: OK
RX: m300018d4,4
TX: 7d821008
RX: M300018d4,4:801c005c
TX: OK

-- GDB is clearing the breakpoints *INCLUDING MY USER BREAKPOINT* - it has removed the
trap instruction and set it back to 0x38000000. why is it doing this!?!

RX: m10010904,b0
TX: 00000001000000010000000c1000036c0000000d1000089c000000041000012800000005100002680000000610000
RX: m30005004,4
TX: 00000000
RX: vCont;s
TX: T0b01:7ffffa60;40:1000056c;
RX: g
TX: 000000007ffffa6000000000000000017ffffb747ffffb7c1000036c1000089c3001d2730000000000000000300d0
RX: m30027074,c
TX: 480b5cb57c601b787c030378
RX: m7ffffa68,4
TX: 00000001
RX: m7ffffa6c,4
TX: 7ffffb74

-- GDB has fallen into the segmentation violation here. I type "c" to continue.

RX: m10000548,4
TX: 38000000
RX: M10000548,4:7d821008
TX: OK
RX: m300018d4,4
TX: 801c005c
RX: M300018d4,4:7d821008
TX: OK
RX: vCont;C0b

-- GDB falls off the end of the program and restores memory back to the original. NOTICE: gdb is restoring the *wrong* 
values - The "RX: M10000548,4:7d821008" command is writing the  trap instruction back out to 
memory, on top of the correct value, 0x380000000.