This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug breakpoints/16494] New: Call-style dprintf does not work with disconnected-dprintf
- From: "marc.khouzam at ericsson dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Wed, 22 Jan 2014 11:51:14 +0000
- Subject: [Bug breakpoints/16494] New: Call-style dprintf does not work with disconnected-dprintf
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=16494
Bug ID: 16494
Summary: Call-style dprintf does not work with
disconnected-dprintf
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: breakpoints
Assignee: unassigned at sourceware dot org
Reporter: marc.khouzam at ericsson dot com
The main use case for any dprintf for us is that they should print to the same
output location as a compiled printf. This can be achieved by using
'dprintf-style call'; that style seems to work properly both for a local GDB
session and for gdbserver. However, for disconnected-dprintf, I believe we
must use the 'dprintf-style agent'; the problem is that the dprintf-agent
prints to the gdbserver console, instead of the inferior output stream.
Right now, when I use the 'call-style' with disconnected dprintf, the inferior
dies with "Trace/BPT trap" or gets a segmentation fault, when GDB disconnects.
To reproduce:
1- in one shell, start gdbserver like this:
gdbserver.7.7 --multi :9999
2- in another shell start a long running process, e.g.,
~/testing/loopfirst
3- in a third shell, run the gdb session:
> gdb.7.7 ~/testing/loopfirst
GNU gdb (GDB) 7.7.50.20140110-cvs
(gdb) l
1 #include <unistd.h>
2 #include <stdio.h>
3
4 int main() {
5 int max = 900;
6 for (int i=0;i<max;i++) {
7 printf("i is %d\n",i);
8 sleep(1);
9 }
10 return 0;
(gdb) set target-async on
(gdb) set pagination off
(gdb) set non-stop on
(gdb) set disconnected-dprintf on
(gdb) set dprintf-style call
(gdb) tar ext :9999
Remote debugging using :9999
(gdb) attach 4955&
Attaching to program: /home/lmckhou/testing/loopfirst, process 4955
[New Thread 4955.4955]
(gdb) Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging
symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libc.so.6
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
dprintf 8,"hello\n"
Dprintf 1 at 0x400570: file loopfirst.cc, line 8.
====> at this time in shell #2, I see "hello" being printed along with the rest
of the inferior output. This is great.
(gdb) q
A debugging session is active.
Inferior 1 [process 4955] will be detached.
Quit anyway? (y or n) y
Detaching from program: /home/lmckhou/testing/loopfirst, process 4955
===> At this point, in shell #2 I get a segmentation fault in loopfirst.
--
You are receiving this mail because:
You are on the CC list for the bug.