1
votes

Envirment is:

target:x86_64 client,runs the program which is striped

Host:x86_64 server ,has code,toolchain,striped program,symbles file for debug

run gdbserver on target:

%gdbserver --multi :1234 /pathtolog/gdb.log

run program on target:

./someprogram &

[1] PID

run gdb on host:

%gdb

(gdb)target extended-remote TARGETIP:1234

(gdb)file someprogram

(gdb)setrootfs pathtorootfs

(gdb)...//set lib path etc.

(gdb)attach PID

...//load everything as normal

...//stop somewhere

(gdb)c

^C^CThe target is not responding to interrupt requests.

Stop debugging it? (y or n)

tried to find the root cause:

on the target:

gdb attach to gdbserver(yes I can use gdb on the target right now,but the target machine shall be released without gdb,symbles,etc. for size).

(gdb) b kill

Breakpoint 1 at 0xf760afb0

(gdb) c

Continuing.

when press ctrl+c from host gdb ,gdbserver will break into the breakpoint

Breakpoint 1, 0xf760afb0 in kill () from /lib/libc.so.6

(gdb)

I'v checked register,the %esp register shows like this:

(gdb) x /32wx 0xffee8070

0xffee8070: 0xfffffe0c 0x00000002 0x00000001 0x00000000

0xfffffe0c = -PID 0x00000002 = SIGINT

some program will get the signalwhen gdbserver continue . so,kill() is good for "SOME PROGRAM",not all.

And I'v use tcpdump monitored data between gdb/gdbserver. If kill() worked (for "GOOD" program),gdbserver will send a packet to gdb.

I'v tried sigmonitor,found out gdbserver didn't send any sigal to "BAD program" in this case.but I can call kill(pid,2) int gdbserver debuging gdb process

(gdb) call kill(PID,2)

then dmesg shows like this

[11902.060722] ==========send_signal===========

          SIG 2 to 6141[a.out], tgid=6141

...

          SIG 19 to 6142[a.out], tgid=6141

[11902.111135] Task Tree of 6142 = {

...

Any ideas?

1

1 Answers

2
votes

Found out a possible match bug of gdbserver. parameter of kill() called by gdbserver is -PID,not PID.

gdbserver sends SIGINT not to the process, but to the process group (-signal_pid). But the attached process is not always a process group leader. If not, "kill (-signal_pid, SIGINT)" returns error and fails to interrupt the attached process.

static void linux_request_interrupt (void)
{
  /* Send a SIGINT to the process group.  This acts just like the user
     typed a ^C on the controlling terminal.  */
-  kill (-signal_pid, SIGINT);
+  kill (signal_pid, SIGINT);
}

This problem remained in gdb-8.1,don't know why they don't think it's a problem.