Re: [patch] Fix CU relative vs. absolute offsets [Re: RFC: problem with DW_OP_GNU_deref_type and dwarf's get_base_type callback]

[Joel Brobecker <brobecker@adacore.com>]

> I do not understand how it can happen.  amd64-entry-value.exp uses precompiled
> amd64-entry-value.s (unless you use runtest COMPILE=1) and sure it fully
> PASSed+PASSes for me.

I did not run with COMPILE=1, so I think what might be happening is
that the linker might be putting your pre-compiled CU first?

> It looks as if some of the GDB features have never worked in real world - just
> in the testcase which have single CU. :-)

That was my guess first I first saw the testcase using them in our
testsuite. But then, I saw that we do a link, so I thought for sure
we have multi-CU exes. But maybe we used to get lucky as explained
in the total blind guess above?

> 2012-03-07  Jan Kratochvil  <jan.kratochvil@redhat.com>
> 
> 	Fix CU relative vs. absolute DIE offsets.
> 	* dwarf2loc.h (dwarf2_fetch_die_location_block): Rename parameter
> 	offset to offset_in_cu.
> 	* dwarf2read.c (process_enumeration_scope): Add CU offset to
> 	TYPE_OFFSET.
> 	(dwarf2_fetch_die_location_block): Rename parameter offset to
> 	offset_in_cu.  New variable offset, add CU offset to OFFSET_IN_CU.
> 
> --- a/gdb/dwarf2loc.h
> +++ b/gdb/dwarf2loc.h
> @@ -61,7 +61,7 @@ const gdb_byte *dwarf2_find_location_expression
>     CORE_ADDR pc);
>  
>  struct dwarf2_locexpr_baton dwarf2_fetch_die_location_block
> -  (unsigned int offset, struct dwarf2_per_cu_data *per_cu,
> +  (unsigned int offset_in_cu, struct dwarf2_per_cu_data *per_cu,
>     CORE_ADDR (*get_frame_pc) (void *baton),
>     void *baton);

I like these renames...

I don't really know the code well enough to give an opinion on
the correctness of the patch, though. I can test them against our
version of GCC 4.7. Will do that and report.

-- 
Joel