From: Joel Brobecker <brobecker@adacore.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: Add support for VxWorks (v3)
Date: Fri, 04 Mar 2011 10:05:00 -0000 [thread overview]
Message-ID: <20110304100434.GG30306@adacore.com> (raw)
In-Reply-To: <201103040936.02472.pedro@codesourcery.com>
> I haven't really looked at the code yet, but, the question
> I think should be answered most importantly, is: do you
> really need partitions at all?
Unfortunately, you do. The most common case is when you are debugging
in system mode. This essentially means debugging the entire system,
and therefore multiple partitions. Another use case is is when
debugging a task that runs some code provided by a shared partition.
It's a little bit like shared libraries on traditional OSes. In that
case, you're effectively debugging over several partitions at the same
time.
I should also repeat that the partition-switching implementation has
been stubbed out (meaning not contributed yet). The reason for that
is that it makes some assumptions about how core GDB accesses its
objfiles. I was under quite a bit of pressure when I implemented this,
and the good news is that it's localized, and never broke in the years
since I wrote the code. I'm keeping my fingers crossed. But what it
does is rebuild GDB's objfile list at each partition switch. This
allows us to give the user the same visibility rules as the code
running loaded in that partition.
I have some ideas of how I would like to integrate that concept
in GDB. There are two issues: (1) we need one list of objfiles
per partition - that should be relatively easy to deal with;
(2) we have some partitions that are a little special: (2a)
the "kernel" partition, which is a partition accessible from
all other partitions; (2b) shared partitions, which can be
accessible from other partitions, provided that the shared
partition is in the "link path" of the client partition (it's
an ordered list of shared partitions). I think we can deal with
the "kernel" partition as being an implicit shared partition -
that would be dealt with at the target level. But we will need
to teach the objfile walking about link paths (not very hard,
I expect).
If cell or any other target could benefit from partitions as well,
I'd be happy to start designing this part sooner rather than later.
I sent an RFC about that many months ago, and got no reply, so
I just assumed little interest. But it would be nice to design
this part with someone else - so far, it's been pretty much me.
--
Joel
next prev parent reply other threads:[~2011-03-04 10:05 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-04 6:22 Joel Brobecker
2011-03-04 6:22 ` [VxWorks 02/20] Some ada-lang/ada-tasks routines needed by the VxWorks target Joel Brobecker
2011-03-04 6:22 ` [VxWorks 05/20] more parsing routines in cli/cli-utils Joel Brobecker
2011-03-04 6:22 ` [VxWorks 04/20] New general purpose routines in utils.c Joel Brobecker
2011-03-04 6:22 ` [VxWorks 03/20] New toplevel_command_post observer Joel Brobecker
2011-03-04 6:22 ` [VxWorks 01/20] fix parameter names in cli/cli-utils.h Joel Brobecker
2011-03-04 6:23 ` [VxWorks 08/20] New modules gdb_dlfcn and remote-wtx-utils Joel Brobecker
2011-03-04 6:23 ` [VxWorks 06/20] add new "unload" command (symetry of existing "load" command) Joel Brobecker
2011-03-04 6:23 ` [VxWorks 10/20] Add options to control Vxworks related settings Joel Brobecker
2011-03-04 6:23 ` [VxWorks 07/20] new struct bp_target_info target_private_data field Joel Brobecker
2011-03-04 6:24 ` [VxWorks 09/20] remote-wtxapi: The WTX API abstraction layer Joel Brobecker
2011-03-04 6:24 ` [VxWorks 13/20] Add partition support Joel Brobecker
2011-03-04 6:24 ` [VxWorks 12/20] "multi-tasks-mode" support Joel Brobecker
2011-03-04 6:24 ` [VxWorks 14/20] remote-wtx-hw: register fetch/store support Joel Brobecker
2011-03-04 6:24 ` [VxWorks 11/20] VxWorks breakpoint-handling module Joel Brobecker
2011-03-04 6:25 ` [VxWorks 20/20] document the new VxWorks port Joel Brobecker
2011-03-04 6:25 ` [VxWorks 16/20] WTX-TCL support module Joel Brobecker
2011-03-04 6:25 ` [VxWorks 18/20] Add tdep files for x86 and powerpc Joel Brobecker
2011-03-04 6:25 ` [VxWorks 15/20] Add new "wtx" target Joel Brobecker
2011-03-04 6:25 ` [VxWorks 19/20] Configury and Makefile updates for VxWorks Joel Brobecker
2011-03-04 6:25 ` [VxWorks 17/20] Add support for VxWorks 6 Joel Brobecker
2011-03-04 9:36 ` Add support for VxWorks (v3) Pedro Alves
2011-03-04 10:05 ` Joel Brobecker [this message]
2011-03-04 10:45 ` Pedro Alves
2011-03-04 12:10 ` Joel Brobecker
2011-03-07 19:49 ` Tom Tromey
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=20110304100434.GG30306@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--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