Re: [rfc] Make DWARF-2 "address size" explicit

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Dan Jacobowitz wrote:
> On Mon, Jan 28, 2008 at 09:52:32PM +0100, Ulrich Weigand wrote:
> > When comparing all this with what GDB currently does, there is
> > one obvious error: GDB does not take the FDE encoding into
> > account *at all* when accessing the operand of DW_CFA_set_loc
> > in the .eh_frame section.  It looks like this was already noticed
> > by Dan some time ago, but the associated patch:
> > 
> > http://www.cygwin.com/ml/gdb-patches/2006-10/msg00063.html
> > 
> > apparently was never applied.  Dan, are you still planning on
> > applying this patch?
> 
> If you could look over that patch and tell me if it looks right, I'll
> apply it.  I had no way to test it with valid debug information.

Your patch certainly looks right to me.  I'm wondering about this
comment, however:

+	      /* Always apply the objfile offset.  We can do this because
+		 if the code used DW_EH_PE_absptr, it probably wasn't
+		 relocatable, so the offset should be zero.  */
+	      fs->pc += ANOFFSET (unit->objfile->section_offsets,
+				  SECT_OFF_TEXT (unit->objfile));

I agree that we should always apply the objfile offset.  In fact,
even in the case of a DW_EH_PE_absptr in a relocatable object,
it *still* should be right to apply the offset: in this case,
there will be a relocation on the .eh_frame section that gets
applied when loading it into memory.  So if we'd read the value
from the in-memory copy, it would be wrong to add any offset.
However, we actually read the section contents via the
symfile_relocate_debug_section routine, which -while it does
apply relocations- assumes every section is located at its 
default offset.  So to get actual addresses we still need to
apply the section offset, right?

Apart from that, just a cosmetic comment:  I was wondering
why you didn't simply add a back-link from struct dwarf2_cie
to its containing struct comp_unit.  Then you'd automatically
have the CU available whereever you already have a CIE or FDE
pointer, without having to add "unit" arguments to all those
functions ...

> > Apart from that, it would appear that the most logical size to
> > use for target addresses in DWARF expression evaluation would
> > be the target "void *" size for .eh_frame FDEs, and the value
> > of the associated compilation unit's .debug_info address size
> > header field value for .debug_frame FDEs (however, I'm not sure
> > how to best determine that).
> 
> DJ Delorie ran into this same mess on the GCC list a few days ago and
> Ian had the helpful suggestion to just avoid the bits that depend on
> the ambiguous "address size".  If enough people do that, maybe it
> won't matter what we pick... I think your choices sound correct.  It's
> hard for .debug_info, though, as there is no direct correlation or
> dependency between the sections.

Yes, unfortunately you cannot look up the CU that corresponds to the
address range covered by the FDE, because to read that address range
you already need to know the address size :-/

You could make a pass over all .debug_info CU headers in the whole
objfile, and check whether they all agree on their address size
value -- I think this should just about always be true, as even on
those targets where GCC supports multiple address sizes (i.e. mips),
they can only be changed via ABI-breaking options, so those should
never be linked together into a single objfile.  If they all *do*
agree, then we have a number we can use ...  Does this make sense?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com