On 07/25/2012 07:54 PM, Sterling Augustine wrote:
On Wed, Jul 25, 2012 at 4:00 PM, Cary Coutant <ccout...@google.com> wrote:
Perhaps instead of having a val_index field in each attribute you should
have the attribute point to something like an indirect_string_node for
addresses as well.
The potential savings here didn't seem worth the effort of adding a
pass over another table to assign slots in .debug_addr. In practice,
we're seeing very few slots zeroed out here.
And how many duplicate entries? What strategy does Cary's patch use to
avoid those?
It also requires a carefully watching when die sizes are measured--if
a leb128 fit inside a byte and then grows to need two bytes, all the
size and die_offset calculations will need to be redone.
I would expect it to be straightforward to assign the indices before
calculating die sizes.
Deferring the choice of representation of the address until output time
should also avoid the need for the "force_direct" parameter on various
functions.
I'm not sure about that. Even if we build a hash table for slots in
.debug_addr, we'll still need to know when we call add_AT_addr or
add_AT_lbl_id whether or not we want to use an indirect reference. In
the cases where force_direct is true, we won't want to add the label
to the hash table.
Right. We would have to track it even with a hash table.
I was thinking that the context of the reference would determine whether
you want a direct or indirect reference, in a way that would be clear
when we go to write out the reference. But if that isn't convenient, I
don't mind determining it when we build the reference.
The added documentation for force_direct tells me what it means, but not
when you would want to pass true or false. What is the pattern here?
Jason
