* Next for GDB @ 2003-08-01 23:46 Andrew Cagney [not found] ` <mailpost.1059781632.20888@news-sj1-1> 0 siblings, 1 reply; 5+ messages in thread From: Andrew Cagney @ 2003-08-01 23:46 UTC (permalink / raw) To: gdb Since 6.0 is starting to look real, I might as well post what I think I'll be working on next. My curent TODO list for gdb includes - rip out the non-multi-arch code - keep chipping away at the frame/thread code - the target vector - the sim vector along with the usual adminstrivia like pestering random lawyers. It would also be nice to see the GDB - BFD interface upgraded a little. Andrew ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <mailpost.1059781632.20888@news-sj1-1>]
* Re: Next for GDB [not found] ` <mailpost.1059781632.20888@news-sj1-1> @ 2003-08-02 1:37 ` cgd 2003-08-05 4:11 ` Andrew Cagney 0 siblings, 1 reply; 5+ messages in thread From: cgd @ 2003-08-02 1:37 UTC (permalink / raw) To: ac131313; +Cc: gdb 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? 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. 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... 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.) cgd ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Next for GDB 2003-08-02 1:37 ` cgd @ 2003-08-05 4:11 ` Andrew Cagney 2003-08-05 4:16 ` Daniel Jacobowitz 0 siblings, 1 reply; 5+ messages in thread From: Andrew Cagney @ 2003-08-05 4:11 UTC (permalink / raw) To: cgd; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Next for GDB 2003-08-05 4:11 ` Andrew Cagney @ 2003-08-05 4:16 ` Daniel Jacobowitz 0 siblings, 0 replies; 5+ messages in thread From: Daniel Jacobowitz @ 2003-08-05 4:16 UTC (permalink / raw) To: Andrew Cagney; +Cc: cgd, gdb On Tue, Aug 05, 2003 at 12:11:49AM -0400, Andrew Cagney wrote: > 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 ... That has got to be one of the neatest ideas I've heard in a long time... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Next for GDB @ 2003-08-02 0:54 Michael Elizabeth Chastain 0 siblings, 0 replies; 5+ messages in thread From: Michael Elizabeth Chastain @ 2003-08-02 0:54 UTC (permalink / raw) To: ac131313, gdb Andrew, what's your judgement on the backtrace bugs with gdb 6.0 branch? Michael C ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-08-05 4:16 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-08-01 23:46 Next for GDB Andrew Cagney [not found] ` <mailpost.1059781632.20888@news-sj1-1> 2003-08-02 1:37 ` cgd 2003-08-05 4:11 ` Andrew Cagney 2003-08-05 4:16 ` Daniel Jacobowitz 2003-08-02 0:54 Michael Elizabeth Chastain
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).