From: Tom Tromey <tromey@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: RFC: partially fix empty DW_OP_piece
Date: Tue, 01 Jun 2010 17:34:00 -0000 [thread overview]
Message-ID: <m3d3wa7lio.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20100514223521.GA3975@host0.dyn.jankratochvil.net> (Jan Kratochvil's message of "Sat, 15 May 2010 00:35:21 +0200")
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
We were talking on irc and Jan asked for more information about part of
my plan...
Tom> The other way is to simply remove val_print entirely and make all of
Tom> printing work using values. I think this is the route I would prefer.
Jan> That could hopefully solve the problem of missing type-associated object
Jan> address for DW_OP_push_object_address for the VLA (variable length arrays)
Jan> patch.
I am curious to know what you need here.
I started by looking briefly at replacing val_print. This looks pretty
big, though. So I looked into other solutions.
I wrote a big patch to pass lval_funcs through all the val_print code.
However, it turns out that this is not sufficient: the code has to
handle value_offset() as well, which means either adding another
argument (the offset) or just passing the original value through.
So, currently I am thinking I will go through my existing patch and have
it pass a value instead of lval_funcs. Of course this means a lot of
redundant info, which is ugly.
There are barriers to removing val_print. I think the biggest one,
conceptually, is that recursion in val_print means making new values,
which means copying the value contents. This can be expensive. (Of
course there are solutions to that, reference counting the value
contents comes to mind.)
Tom
next prev parent reply other threads:[~2010-06-01 17:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-14 6:39 Tom Tromey
2010-05-14 22:51 ` Jan Kratochvil
2010-05-21 19:48 ` Tom Tromey
2010-06-01 17:34 ` Tom Tromey [this message]
2010-06-02 18:54 ` Jan Kratochvil
2010-06-02 20:07 ` Tom Tromey
2010-06-03 17:46 ` Jan Kratochvil
2010-06-04 19:05 ` Tom Tromey
2010-06-04 19:10 ` Jan Kratochvil
2010-06-04 21:39 ` Tom Tromey
2010-06-04 21:47 ` Jan Kratochvil
2010-05-20 23:04 ` Joel Brobecker
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=m3d3wa7lio.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@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