Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Stan Shebs <stan@codesourcery.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb@sourceware.org, Stan Shebs <stan@codesourcery.com>,
	  Mark Kettenis <mark.kettenis@xs4all.nl>
Subject: Re: Towards multiprocess GDB
Date: Mon, 21 Jul 2008 17:39:00 -0000	[thread overview]
Message-ID: <4884C325.4060906@codesourcery.com> (raw)
In-Reply-To: <200807190013.24604.pedro@codesourcery.com>

Pedro Alves wrote:
> A Friday 18 July 2008 23:27:58, Stan Shebs wrote:
>
>   
>> I'm not sure it's going to be that big of a change actually. Once
>> behavior has been directed to the right objects internally, they will do
>> what they're doing now. Most symbol handling is objfile-relative for
>> instance, adding a new set of objfiles for a different exec isn't going
>> to affect that code.
>>     
>
> You seem to be thinking of the symbol handling code only.
>
> The thing I see requiring architecting, is the target stack.
>   
You make very good points about the target stack. As I understand it, 
the immediate project is merely to support multiple programs all using 
the same target, so I've been concentrating on the symbol side. But 
you're right, I think we do want the target objects to be per-program.

This connects to another longstanding wishlist item, which is to change 
target stacking to be more procedural, and less literally stacklike. 
With multiple programs, and inferiors scattered around the net, the 
target "stack" starts looking more forest-like, and it seems like it 
might be simpler to construct target objects as compositions of target 
descriptions, with the stack being more like the composition procedure 
than a literal stack.

Thinking about it from the user point of view, I wonder if we need to 
merge the "target", "run", and "attach" commands into some kind of 
super-command that amounts to "get all the inferiors ready to debug", so 
that the old commands are all special cases.

Stan


  reply	other threads:[~2008-07-21 17:11 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-18 20:50 Stan Shebs
2008-07-18 21:21 ` Paul Koning
2008-07-18 21:41   ` Stan Shebs
2008-07-21  0:34   ` Michael Snyder
2008-07-18 22:13 ` Mark Kettenis
2008-07-18 22:20   ` David Daney
2008-07-18 22:28   ` Thiago Jung Bauermann
2008-07-18 23:09   ` Stan Shebs
2008-07-19  3:53     ` Pedro Alves
2008-07-21 17:39       ` Stan Shebs [this message]
2008-07-21  1:53   ` Michael Snyder
2008-07-21 16:08     ` Russell Shaw
2008-07-21 17:57   ` Joel Brobecker
2008-07-18 23:13 ` Tom Tromey
2008-07-21 17:11   ` Stan Shebs
2008-07-21  0:30 ` Michael Snyder
2008-07-21 18:21   ` Paul Pluzhnikov
2008-07-21 18:32   ` Stan Shebs
2008-07-21 16:38 ` Michael Eager
2008-07-21 21:54   ` Stan Shebs
2008-07-31 22:04 ` Ian Lance Taylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4884C325.4060906@codesourcery.com \
    --to=stan@codesourcery.com \
    --cc=gdb@sourceware.org \
    --cc=mark.kettenis@xs4all.nl \
    --cc=pedro@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox