From: Daniel Jacobowitz <drow@false.org>
To: Tom Tromey <tromey@redhat.com>
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>, gdb-patches@sourceware.org
Subject: Re: [patch] Support DW_OP_call2 and DW_OP_call4 (PR 10640)
Date: Mon, 12 Oct 2009 21:08:00 -0000 [thread overview]
Message-ID: <20091012210844.GA20340@caradoc.them.org> (raw)
In-Reply-To: <m3aazwqr6v.fsf@fleche.redhat.com>
On Mon, Oct 12, 2009 at 02:43:04PM -0600, Tom Tromey wrote:
> Yeah, I could not think of a way to avoid it either. I think parsing
> the DWARF while reading would be worse than what you have now, because
> (IIUC) it would negatively impact performance.
This is all part of inter-CU references. You can't (always) parse it
as you read it in; there can be dependency loops.
I'm confused as to why the "struct symbol" comes into this though.
We're just using it to look up its DWARF location again. Can we do
this directly off the target DIE? We don't free up the loaded
.debug_info (partly to support DW_FORM_string). And we have
infrastructure to load a given CU's dies whenever we need them.
IIUC this would require a different implementation of the baton
for DIEs without a symbol.
--
Daniel Jacobowitz
CodeSourcery
prev parent reply other threads:[~2009-10-12 21:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-20 12:37 Jan Kratochvil
2009-10-12 20:43 ` Tom Tromey
2009-10-12 20:49 ` Tom Tromey
2010-06-07 11:56 ` [patch 1/2] DW_OP_call: Provide per_cu in the batons Jan Kratochvil
2010-06-07 17:44 ` Tom Tromey
2010-06-07 19:44 ` Jan Kratochvil
2010-06-07 11:56 ` [patch 2/2] DW_OP_call: Support DW_OP_call2 and DW_OP_call4 Jan Kratochvil
2010-06-07 18:13 ` Tom Tromey
2010-06-07 20:00 ` Jan Kratochvil
2010-06-07 11:56 ` [patch 0/2] DW_OP_call: Re: [patch] Support DW_OP_call2 and DW_OP_call4 (PR 10640) Jan Kratochvil
2009-10-12 21:08 ` Daniel Jacobowitz [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=20091012210844.GA20340@caradoc.them.org \
--to=drow@false.org \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=tromey@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