Re: RFC Dwarf2 referent dies

[Daniel Berlin <dberlin at dberlin dot org>]

>
> To get the DW_AT_type of function foobar():
> 1. Read at offset 0xd5 DW_FORM_ref_addr ---that tells you to go to--->
> 2. Read at offset 0x87 DW_FORM_ref_udata ---that tells you to go read
>                                           offset of 0x38 of the compilation
>                                           unit.
>
> The problem comes in when dwarf2_get_ref_die_offset() is called to figure
> this out.  The offset that is added to the attribute is set to the original
> compilation unit.  Since we have arrived by the "back door", we don't know
> the compilation unit's offset:

Not that we actually *need* to know it beforehand, we just have to realize
it's not necessarily the same, and go hunting for the right CU in that
case.

 > dwarf2_get_ref_die_offset()
>     switch (attr->form)
>     {
>     case DW_FORM_ref_addr:
>       result = DW_ADDR (attr);
>       break;
>     case DW_FORM_ref1:
>     case DW_FORM_ref2:
>     case DW_FORM_ref4:
>     case DW_FORM_ref8:
>     case DW_FORM_ref_udata:
>       result = cu_header_offset + DW_UNSND (attr);
>                ^^^^^^^^^^^^^^^
>       break;
>
> My proposal for working around this problem is based on an old patch from
> Daniel Berlin.

Whoops, you don't want to use my code. It's horrendous, ugly, evil, and
bad. Just ask Andrew. (Even though it works fine and has been used without
trouble by people for years).  I'm surprised your gdb doesn't explode into
flames just by including it.

> The idea is to create a binary tree of compilation unit headers
> using a splay algorithm and walk through the table and look
> at the offset and length of each compilation unit.  Then find a compilation
> unit that contains this offset.

This also means being able to read in a CU on demand because we might be
at a DIE that is in a currently unread CU.
> I used a splay tree because it seems that
> a developer generally works on one area of the code and that keeps the
> most used compilation units at the top of the tree where they are quick to
> find.  Then dwarf2_get_ref_die_offset() snippet would look something like this:
>
>   switch (attr->form)
>     {
>     case DW_FORM_ref_addr:
>       result = DW_ADDR (attr);
>       break;
>     case DW_FORM_ref1:
>     case DW_FORM_ref2:
>     case DW_FORM_ref4:
>     case DW_FORM_ref8:
>     case DW_FORM_ref_udata:
>       result = find_cu_header_offset(offset, objfile);
>       if (result == FALSE)
>           {
>               complain (&dwarf2_unknown_cu_offset, offset);
>               return 0;
>           }
>       result += DW_UNSND (attr);
>       break;
>
> I implemented this in 5.0 and although the change was pretty invasive it has
> seemed to work for a couple of years.

The change was invasive because the dwarf2 reader is globals happy.
It needed a severe amount of simple rewrites that touch almost every
function in order to be able to do it right.
Where right means not having to read the entire debug info section just to
get at a given CU.

> I would like to take advantage of the
> new location list changes and better C++ support in the current GDB but
> can't do it until something like this is in the current GDB source base.

You could reimplement on top of what's in the current gdb tree.
However, it's a bit of work, since while the structure for multiple cu's
is there (struct comp_unit_head has a next  pointer), it's not actually
used (You can #if 0 out the next member and it'll still compile).
In addition, there are still plenty of places that assume one CU at a time
only (using the die_ref table for instance).

I went from a linked list to a splay tree specifically because linearly
searching all the CU's to find the right one was too slow.


> Comments?
>

Feel free to clean up your patch and make it apply to the head, and
submit it.  If you aren't sure how, send it to me and i'll update it for
you.
Or redo it using what's there now, and live with the increased memory
usage.
However, i'm not going to submit it for review/inclusion, and shepard it
through the process. You'd have to do that.
> Tim Combs
>