libGDB architecture

Todd Whitesel
Thu Aug 26 22:29:00 GMT 1999

> In the first case, there is a chance that the target could die part way
> through an exchange.  That in turn could cause GDB to hang until a timer
> kicks in.  It was felt that the probability of this was low and the
> amount of effort needed to handle this case providing marginal return.
> As a second pass (or as contributed code) this can be re-worked into a
> simpler interface.

Reasonable enough.

I must say though, one of my biggest complaints against the innards of MULTI
was that the synchronous heritage from ptrace() was rampant and was lousy for
embedded, where we can have targets dying and the debugger UI freezing solid
while a compile is going on in another window ... customers really hate that.

Various attempts to solve this often resulted in the UI event loops being
re-entered, which has its own host of dangers. I fought hard for the idea
of state-machining tasks that block in vulnerable places, so we could just
call everything from the top of the event loop and not have problems. The
people whose backing I needed for it pooh-poohed the idea for a couple years,
but about the time I was quitting I discovered that the guy promoted to head
up MULTI had quietly started working on it and was mostly finished.

> Yes, eventually.  The target-output is driven by the need to support
> embedded targets.  Native targets currently by-pass GDB when displaying
> output.  I recall Jim Ingham explaining that a UNIX gui debugger should
> create a separate window with PTY and start the program under that.

Just want to point out that this needs to be optional. Sometimes you just
have to debug that blankety-blank termio[s] code because it wants to fail
on the tty devices for that weird 3rd party 8-port serial board ...

Todd Whitesel
toddpw @

More information about the Gdb mailing list