This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: interface to partial support for DW_OP_piece in dwarf2expr.[ch]
- From: Jim Blandy <jimb at redhat dot com>
- To: Mark Kettenis <kettenis at jive dot nl>
- Cc: drow at false dot org, cagney at gnu dot org, gdb at sources dot redhat dot com
- Date: 05 Aug 2004 09:28:21 -0500
- Subject: Re: interface to partial support for DW_OP_piece in dwarf2expr.[ch]
- References: <vt2fz743d9h.fsf@zenia.home> <4111145F.7000504@gnu.org><vt2fz7292z3 dot fsf at zenia dot home> <41112BAE dot 9080304 at gnudot org> <vt2hdri4mi1 dot fsf at zenia dot home> <41115B4F dot 1080700at gnu dot org> <vt2pt66zgul dot fsf at zenia dot home><20040804230242 dot GA10332 at nevyn dot them dot org><vt2wu0ejy1q.fsf@zenia.home><200408050952.i759qXFK010181@juw15.nfra.nl>
Mark Kettenis <kettenis@jive.nl> writes:
> It seems worthwhile to me, because it will allow GDB to work
> correctly, assignments and all, in the cases where the current value
> structures can handle it, and it's very little work. At some point,
> resources will materialize to do the larger project, but what's the
> harm in getting the best behavior we can out of the current structures
> until then?
>
> The harm is introducing hacks that are very hard to remove in the
> feature. GDB is full of such hacks, and apart from Andrew nobody
> seems to actively work on trying to remove these. We really don't
> need any more of them.
That is a good argument for not adding something. But this will be
trivial to remove. You'll just delete it.
Once 'struct value' can handle arbitrary piece lists, there will be no
need to try to reduce Dwarf expression results to a simpler form.
You'll instead have arch-independent code that takes any result of
Dwarf location expression evaluation and produces an assignable value.
Every case that the reduction arch method would handle will be
supported by arch-independent code instead. So if the intermediate
step of reducing piece lists we couldn't formerly handle to locations
we could simply stops happening, there will be no visible change in
behavior.
We know the cases supported by the arch-independent code will be a
superset of the cases supported by the arch-dependent reducer. The
latter can only support cases that can be reduced to our current
'struct value', and the arch-independent implementation will extend
that.
Again, I don't see any need for GDB to be broken until the larger
project is complete. GDB is broken for targets today that could use
this reduction method.