From: Tom Tromey <tromey@redhat.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] [1/2] First cut at multi-executable support.
Date: Fri, 26 Jun 2009 19:11:00 -0000 [thread overview]
Message-ID: <m34ou2dd8b.fsf@fleche.redhat.com> (raw)
In-Reply-To: <200906251541.04243.pedro@codesourcery.com> (Pedro Alves's message of "Thu\, 25 Jun 2009 15\:41\:03 +0100")
>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
Pedro> We could split an objfile in two, with the shared parts not having a
Pedro> reference to a symbol space. [...]
Pedro> At a high distance, this sounds feasible to me, but, looking at the
Pedro> code, this looks like a huge effort, and I'm sure I'm missing a lot
Pedro> of complications.
Yeah. I just find it helpful to have an overview of the wish-list.
Tom> This seems like another possible performance problem; lazily reading
Tom> it would be friendlier. In a scenario like the "make" case, I would
Tom> assume that most inferiors will not actually require any user
Tom> attention, and time and memory spent on their debuginfo is just
Tom> wasted.
Pedro> Yeah, I know you have patches for this. ;-)
Hah, yeah, I was kind of plugging my patch. I'm hoping that we can
actually push this lazy reading idea much further -- with my patch,
the pause when gdb actually goes to read the debuginfo can be rather
noticeable on occasion. But, this is vague dreaming, I don't really
know how to implement full laziness yet.
Tom> "Program exited normally." could also use some love... at least some
Tom> info about the program, and maybe removing the excess newlines?
Pedro> For my own testing, I've tweaked those messages to include the
Pedro> process id. It's just mad otherwise. However, it has been
Pedro> one of my goals to not change much how the single-inferior case
Pedro> works/outputs as a first incremental step. I'm sure there will
Pedro> be different opinions on to what GDB should output, so this avoids
Pedro> such discussions for now :-).
Practical plan :-)
Tom> + ui_out_table_header (uiout, 1, ui_left, "current", "");
Tom> For some reason I did not think of leaving the header empty when I did
Tom> this for "info inferiors". I like this better... since you're also
Tom> touching print_inferior, how about just making that change?
Pedro> But I had already. :-) Or, do you mean to split that change out
Pedro> of the patch? I can do that. I think that would be good idea.
I thought your patch had this change in one place but not "info
inferiors". Maybe I missed it. Anyway, don't worry about it, I'll
mark this note and go back and check once everything goes in.
Pedro> I'm now working on cleaning up a bit the patch and fixing the
Pedro> random crashes I mentioned, and I'll be posting an updated
Pedro> patch soon.
I'm looking forward to it.
Tom
prev parent reply other threads:[~2009-06-26 19:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-15 15:22 Pedro Alves
2009-06-15 15:51 ` Pedro Alves
2009-06-17 18:19 ` Tom Tromey
2009-06-25 14:40 ` Pedro Alves
2009-06-26 19:11 ` Tom Tromey [this message]
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=m34ou2dd8b.fsf@fleche.redhat.com \
--to=tromey@redhat.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