public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@redhat.com>
To: cgd@broadcom.com
Cc: gdb@sources.redhat.com
Subject: Re: Next for GDB
Date: Tue, 05 Aug 2003 04:11:00 -0000	[thread overview]
Message-ID: <3F2F2E85.8070805@redhat.com> (raw)
In-Reply-To: <yov5r844zvp9.fsf@ldt-sj3-010.sj.broadcom.com>

> Is today Scary Andrew Mail Day?  8-)
> 
> At Fri, 1 Aug 2003 23:47:12 +0000 (UTC), "Andrew Cagney" wrote:
> 
>> [ ... ]  My curent TODO list for gdb includes
>> 
>> [ ... ]
>> - the sim vector
> 
> 
> What's on your to-do list there?

`all of the below'?  See the sim category in the bug database.

> If there's going to be much work on the interface to the simulator,
> one thing that *should* be implemented IMO is some mechanism to allow
> multiple processors in a simulator to be exposed to GDB, probably
> using some thread-related mechanism.

yep.

both GDB's target vector, and the simulator vector need an upgrade.

> I've not looked into GDB's thread bits for about a year and a half, i
> don't recall if it splits the notion of 'user thread' vs. 'kernel
> context' (i.e., M and N in MxN threading systems) or tries to make any
> such distinction.  Multiple cores would kind-of correspond to multiple
> kernel contexts...

yep.

gdb currently isn't well structured enough to do this.

It's also related to getting GDB to handle backtraces through 
interpreters.  It could be done with further target layers, or perhaphs 
frame layers...

For the moment, I'm just worred about making the architecture code 
non-global.

> i've got a year and a half old diff that starts adapting some old
> version of GDB (5.2?) to support multiple cores/threads under
> simulation, if somebody wants it.
> 
> 
> (in order to support debugging multiple cores in our gdb+simulator --
> again a plug for http://sibyte.broadcom.com/public/resources/#tools --
> we currently use a fairly nasty but functional hack.  I started to try
> to fix that, but then that business trip ended and lack of
> productivity resumed.)

Also `making a dead cat bounce'.  Layering a simulator over the top of 
another target so the simulator uses the target for registers and 
memory.  Would make possible:
- less intrusive inferior function calls (don't write the results back)
- executing code on dead targets
- simulated single stepping
this would involve a lot more work so ...

Andrew


  reply	other threads:[~2003-08-05  4:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-01 23:46 Andrew Cagney
     [not found] ` <mailpost.1059781632.20888@news-sj1-1>
2003-08-02  1:37   ` cgd
2003-08-05  4:11     ` Andrew Cagney [this message]
2003-08-05  4:16       ` Daniel Jacobowitz
2003-08-02  0:54 Michael Elizabeth Chastain

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=3F2F2E85.8070805@redhat.com \
    --to=ac131313@redhat.com \
    --cc=cgd@broadcom.com \
    --cc=gdb@sources.redhat.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).