This is the mail archive of the
mailing list for the GDB project.
Re: RFC: partially fix empty DW_OP_piece
- From: Tom Tromey <tromey at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 01 Jun 2010 10:41:51 -0600
- Subject: Re: RFC: partially fix empty DW_OP_piece
- References: <firstname.lastname@example.org> <20100514223521.GA3975@host0.dyn.jankratochvil.net>
- Reply-to: tromey at redhat dot com
>>>>> "Jan" == Jan Kratochvil <email@example.com> writes:
We were talking on irc and Jan asked for more information about part of
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)
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.)