* libgdb
@ 2002-11-22 14:26 a2782
2002-11-22 14:52 ` libgdb Keith Seitz
0 siblings, 1 reply; 12+ messages in thread
From: a2782 @ 2002-11-22 14:26 UTC (permalink / raw)
To: gdb
Hi to all!
I am involved in a project of making a educational graphic interface
and we are thinking about putting it over GDB. My question is: Has
anybody worked with libgdb? My first approximation is invoking gdb as
Emacs does, but using libgdb. I hope someone has worked with libgdb and
can help and advise me.
Thanks in advance!
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: libgdb
2002-11-22 14:26 libgdb a2782
@ 2002-11-22 14:52 ` Keith Seitz
2002-11-22 15:03 ` libgdb Joel Brobecker
0 siblings, 1 reply; 12+ messages in thread
From: Keith Seitz @ 2002-11-22 14:52 UTC (permalink / raw)
To: a2782; +Cc: gdb
On Fri, 22 Nov 2002 a2782@dis.ulpgc.es wrote:
> I am involved in a project of making a educational graphic interface
> and we are thinking about putting it over GDB. My question is: Has
> anybody worked with libgdb? My first approximation is invoking gdb as
> Emacs does, but using libgdb. I hope someone has worked with libgdb and
> can help and advise me.
Sadly, libgdb is a pipedream, and still quite a ways off (but it's
getting closer almost every day).
There are three ways to commonly interface some sort of GUI application
top of GDB:
1) Invoke GDB and parse the command line (emacs does this)
2) Invoke GDB's MI interpreter and write yourself an MI parser (Eclipse
and Apple's tools for MacOS X do this)
3) Write your GUI using GDB's hooks and events (Insight does this)
Obviously, #2 is the most desirably way to isolate yourselves from GDB
changes. Unfortunately, MI is still a work in progress. (Of course, I'm
still partial to #3 for speed.. ;-)
Keith
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: libgdb
2002-11-22 14:52 ` libgdb Keith Seitz
@ 2002-11-22 15:03 ` Joel Brobecker
0 siblings, 0 replies; 12+ messages in thread
From: Joel Brobecker @ 2002-11-22 15:03 UTC (permalink / raw)
To: Keith Seitz; +Cc: a2782, gdb
> 1) Invoke GDB and parse the command line (emacs does this)
> 2) Invoke GDB's MI interpreter and write yourself an MI parser (Eclipse
> and Apple's tools for MacOS X do this)
> 3) Write your GUI using GDB's hooks and events (Insight does this)
>
> Obviously, #2 is the most desirably way to isolate yourselves from GDB
> changes. Unfortunately, MI is still a work in progress. (Of course, I'm
> still partial to #3 for speed.. ;-)
One advantage of method #1 or #2, used by GVD, is that GDB is a separate
process. This GDB process does not need to run on the same host as GVD.
Even if I'm debugging on a distant machine, I can run GVD on my local
machine, reducing tremendously the network traffic. Given that I live in
the west coast, and that most machines I work on are located in NY and
Paris, this is a definite plus.
I think GVD uses method #1, but I would recommend method #2 as the
output is most probably easier to parse.
--
Joel
^ permalink raw reply [flat|nested] 12+ messages in thread
* libgdb
@ 2007-11-02 16:45 Matthew Hall
2007-11-02 16:58 ` libgdb Daniel Jacobowitz
2007-11-02 20:30 ` libgdb Stan Shebs
0 siblings, 2 replies; 12+ messages in thread
From: Matthew Hall @ 2007-11-02 16:45 UTC (permalink / raw)
To: gdb
I've seen references to a libgdb project.
Can anyone tell me if libgdb is still active?
Is it complete?
Is it used internally by gdb itself?
Thanks for any info or links to useful documentation.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: libgdb
2007-11-02 16:45 libgdb Matthew Hall
@ 2007-11-02 16:58 ` Daniel Jacobowitz
2007-11-02 20:30 ` libgdb Stan Shebs
1 sibling, 0 replies; 12+ messages in thread
From: Daniel Jacobowitz @ 2007-11-02 16:58 UTC (permalink / raw)
To: Matthew Hall; +Cc: gdb
On Fri, Nov 02, 2007 at 04:45:45PM +0000, Matthew Hall wrote:
> I've seen references to a libgdb project.
> Can anyone tell me if libgdb is still active?
No.
> Is it complete?
No.
> Is it used internally by gdb itself?
No clear answer to this. There was a "libgdb interface"; some bits of
GDB use it, other bits do not. It's all linked in together.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: libgdb
2007-11-02 16:45 libgdb Matthew Hall
2007-11-02 16:58 ` libgdb Daniel Jacobowitz
@ 2007-11-02 20:30 ` Stan Shebs
1 sibling, 0 replies; 12+ messages in thread
From: Stan Shebs @ 2007-11-02 20:30 UTC (permalink / raw)
To: Matthew Hall; +Cc: gdb
Matthew Hall wrote:
> I've seen references to a libgdb project.
>
An idea left over from ancient days, never got off the ground. The
theory was that one could link it into both the traditional command-line
frontend and into various GUIs. Lots of technical difficulties, two
chief ones being that 1) it would have had to be a very "wide" API in
order to be sufficient to cover all of GDB functionality, and 2) the
library would have to be able to hand control back to the UI on demand,
difficult when inferior control uses blocking system calls. In practice,
it seems to work well enough to have the GUI be a separate program that
communicates with GDB, whether via command line or MI (machine
interface) syntax, and there is some advantage to the "firewalling"
inherent in a two-program scheme, so there's not much motivation to do a
libgdb anymore.
Stan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Frame handling
@ 2003-07-01 1:20 Jafa
2003-07-01 3:42 ` Daniel Jacobowitz
0 siblings, 1 reply; 12+ messages in thread
From: Jafa @ 2003-07-01 1:20 UTC (permalink / raw)
To: gdb
Hi all,
I am bringing the ip2k port back in sync with the trunk and I need to check
my (limited) understanding of the new scheme...
This email is mostly a ramble about my understanding of the new frame
handling that I would like a sanity check on.
frame_base_set_default (gdbarch, &avr_frame_base) registers a set of
function handlers:
this_base - given a frame, figure out the base address of the caller frame
(caller's FP)... usually this means doing some analysis to figure everything
out about the frame and populating the port-specific cache for this new
frame.
this_locals - given a frame, figure out the address of the local variables
of the callers frame (usually caller's FP as debug info already allows for
the offset).
this_args - given a frame, figure out the address of the args passed to the
callers frame (usually caller's FP as debug info already allows for the
offset).
Port specific implementation... The first time one of these functions is
called the port-specific cache will be a NULL pointer... the code should
allocate memory to hold the useful frame variables and figure out the frame
information. Subsequent calls will receive the cache back and can return the
values from the cache.
frame_base_set_default also sets the unwind options...
type - always NORMAL_FRAME?
this_id - Given a frame, return a unique identifier for the caller's frame
based on the caller's frame base address and the calling functions entry
point.
prev_register - Given a frame, return the value of a specified register as
it was on entry to this function (registers that are known to be saved on
the stack)
Question - what registers is gdb expecting prev_register to give reasonable
results for? Just PC? Or SP and FP as well?
Question - reading through this again I think the goal of call these
functions is to work with the current frame and the function get passed the
child frame so they can do a backtrace if it hasn't already been done... why
not call a function to do a 1 level backtrace and then eliminate the
next_frame parameter? It would recduce confusion and most ports will have an
internal unwind function anyway.
frame_unwind_append_predicate (gdbarch, d10v_frame_p) - this seams to
register the same unwind options as above?
I think this makes sense but I would appreciate a sanity check :-)
Thanks
Nick
Nick Kelsey
Senior Software Engineer
Ubicom
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Frame handling
2003-07-01 1:20 Frame handling Jafa
@ 2003-07-01 3:42 ` Daniel Jacobowitz
[not found] ` <redirect-6800274@silicondust.com>
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Jacobowitz @ 2003-07-01 3:42 UTC (permalink / raw)
To: Jafa; +Cc: gdb
On Mon, Jun 30, 2003 at 06:18:33PM -0700, Jafa wrote:
> Hi all,
>
> I am bringing the ip2k port back in sync with the trunk and I need to check
> my (limited) understanding of the new scheme...
>
> This email is mostly a ramble about my understanding of the new frame
> handling that I would like a sanity check on.
>
> frame_base_set_default (gdbarch, &avr_frame_base) registers a set of
> function handlers:
> this_base - given a frame, figure out the base address of the caller frame
> (caller's FP)... usually this means doing some analysis to figure everything
> out about the frame and populating the port-specific cache for this new
> frame.
> this_locals - given a frame, figure out the address of the local variables
> of the callers frame (usually caller's FP as debug info already allows for
> the offset).
> this_args - given a frame, figure out the address of the args passed to the
> callers frame (usually caller's FP as debug info already allows for the
> offset).
>
> Port specific implementation... The first time one of these functions is
> called the port-specific cache will be a NULL pointer... the code should
> allocate memory to hold the useful frame variables and figure out the frame
> information. Subsequent calls will receive the cache back and can return the
> values from the cache.
You're good so far.
> frame_base_set_default also sets the unwind options...
No, it doesn't. That unwind member is used for comparison purposes
only. See the "Sneaky" comment in get_frame_base_address, and all of
"frame-unwind.h". Esp. frame_unwind_append_predicate.
> type - always NORMAL_FRAME?
For a target's unwinders, probably.
> this_id - Given a frame, return a unique identifier for the caller's frame
> based on the caller's frame base address and the calling functions entry
> point.
> prev_register - Given a frame, return the value of a specified register as
> it was on entry to this function (registers that are known to be saved on
> the stack)
>
> Question - what registers is gdb expecting prev_register to give reasonable
> results for? Just PC? Or SP and FP as well?
As many as possible. This _completely_ replaces all other unwinding,
for instance frame_chain and the extra_info/saved_registers data.
Might want to take a look at the ARM conversion I just posted; I don't
promise it's right...
> Question - reading through this again I think the goal of call these
> functions is to work with the current frame and the function get passed the
> child frame so they can do a backtrace if it hasn't already been done... why
> not call a function to do a 1 level backtrace and then eliminate the
> next_frame parameter? It would recduce confusion and most ports will have an
> internal unwind function anyway.
Because it doesn't make much difference, I think. The key is that the
info generated when doing the backtrace is target specific, and opaque.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 12+ messages in thread
* gdb's communication to a process/libgdb?
@ 2003-04-16 19:59 Smita
2003-04-16 22:07 ` libgdb Smita
0 siblings, 1 reply; 12+ messages in thread
From: Smita @ 2003-04-16 19:59 UTC (permalink / raw)
To: Smita; +Cc: gdb
Hi,
I am spawing a gdb process from my process and feeding to gdb an input
script.
I want the parent process to be able to control this gdb process. For this
to happen, I want to communicate to the parent process that a breakpoint
has occurred when gdb stops at a breakpoint? Is it possible to to this?
There is something called libgdb. I am not sure if that can be used for
this purpose.
Any feedback on this would be greatly appreciated.
Thanks
Smita
^ permalink raw reply [flat|nested] 12+ messages in thread
* libgdb
@ 2002-10-23 22:46 Satya
0 siblings, 0 replies; 12+ messages in thread
From: Satya @ 2002-10-23 22:46 UTC (permalink / raw)
To: gdb
Hi,
I am new to libgdb.Can some one tell me how I can use libgdb to
construct an object containing the result of the gdb command.
Thanks,
Satya
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2007-11-02 20:30 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-11-22 14:26 libgdb a2782
2002-11-22 14:52 ` libgdb Keith Seitz
2002-11-22 15:03 ` libgdb Joel Brobecker
-- strict thread matches above, loose matches on Subject: below --
2007-11-02 16:45 libgdb Matthew Hall
2007-11-02 16:58 ` libgdb Daniel Jacobowitz
2007-11-02 20:30 ` libgdb Stan Shebs
2003-07-01 1:20 Frame handling Jafa
2003-07-01 3:42 ` Daniel Jacobowitz
[not found] ` <redirect-6800274@silicondust.com>
2003-07-01 5:13 ` Jafa
2003-07-01 12:58 ` Andrew Cagney
2003-07-01 14:09 ` Daniel Jacobowitz
[not found] ` <redirect-6810110@silicondust.com>
2003-07-01 17:00 ` Jafa
2003-07-02 7:13 ` libgdb jacques
2003-04-16 19:59 gdb's communication to a process/libgdb? Smita
2003-04-16 22:07 ` libgdb Smita
2003-04-17 1:44 ` libgdb Elena Zannoni
2003-04-17 2:06 ` libgdb Smita
2003-04-17 12:57 ` libgdb Elena Zannoni
2002-10-23 22:46 libgdb Satya
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).