From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: Eli Zaretskii Cc: guinan@bluebutton.com, gdb@sources.redhat.com Subject: Re: Asynchronous GDB Date: Thu, 04 Jan 2001 15:44:00 -0000 Message-id: <5m1yuiubkw.fsf@jtc.redback.com> References: <1659-Thu04Jan2001225150+0200-eliz@is.elta.co.il> X-SW-Source: 2001-01/msg00008.html >>>>> "Eli" == Eli Zaretskii writes: >> Date: Thu, 4 Jan 2001 15:10:05 -0500 (EST) >> From: Jamie Guinan >> >> I'm interested in GDB's ability to run asynchronously, like being able to >> examine and modify values without stopping the debugged program. Eli> Forgive me a possibly stupid question, but what does it mean, in Eli> practice, to examine and modify values without stopping the debugged Eli> program? If the debuggee continues to run, the values continue to Eli> change right under your feet, yes? So how do you make sense out of Eli> several values you examine, without having a clue whether they are Eli> consistent with each other or not? While you're correct that it's difficult to debug a live system, in some cases it can also be the only way a bug can tracked down. For example, consider debugging a aggregation router that "can't" go down. It mostly works, so the customer doesn't want to boot many of their paying customers for you to track down the bug. With a little luck, you can peek around global data structures, memory mapped i/o registers, etc. and get a idea of what might be wrong. If not, well, you've done your best. I've done this a bit myself under vxWorks. When you connect to the WDB agent and not connected to a task, you can still read and write memory. I wish the remote protocol was the same way. --jtc -- J.T. Conklin RedBack Networks >From fanny.sassoon@st.com Fri Jan 05 02:00:00 2001 From: Fanny SASSOON To: gdb@sources.redhat.com Subject: RTOS and gdb Date: Fri, 05 Jan 2001 02:00:00 -0000 Message-id: <3A559AB8.807F4E90@st.com> References: X-SW-Source: 2001-01/msg00009.html Content-length: 138 Hello everybody, I wondered if gdb could be used for debugging real-time operating systems? Thanks in advance for your answers. Fanny >From jcownie@etnus.com Fri Jan 05 02:30:00 2001 From: James Cownie To: gdb@sourceware.cygnus.com Cc: Jamie Guinan Subject: Re: Asynchronous GDB Date: Fri, 05 Jan 2001 02:30:00 -0000 Message-id: <14EU7B-0mE-00@etnus.com> X-SW-Source: 2001-01/msg00010.html Content-length: 847 Jamie Guinan wrote : > I'm interested in GDB's ability to run asynchronously, like being able to > examine and modify values without stopping the debugged program. Depending on the operating system this may not be possible no matter how gdb works. On systems which use the ptrace interface for debugging (e.g. Linux, AIX) the ptrace system call itself _requires_ that the target process be stopped before allowing the debugger to delve around inside it. Taking linux/x86 as a "for instance", here's the relevant code for the sys_ptrace in arch/i386/kernel/ptrace.c ... if (child->state != TASK_STOPPED) { if (request != PTRACE_KILL) goto out; } ... In other words the only thing you can do via ptrace to an unstopped process is kill it. -- Jim James Cownie Etnus, LLC. +44 117 9071438 http://www.etnus.com