Re: [PATCH 3/3] dwarf-reader: Ignore zero length location expressions from DW_AT_location

[Mark Wielaard <mark@klomp.org>]

Hi,

On Thu, 2020-10-29 at 12:30 +0000, Matthias Maennich wrote:
> On Thu, Oct 29, 2020 at 12:21:00PM +0000, Matthias Maennich wrote:
> > Location expressions might occasionally be of length 0. E.g. a reason
> > for that are thread local variables that do not exactly have a location
> > to refer to. Compilers/Linkers may choose an odd representation. E.g.
> > see the dwarfdump output for the added testcase based on libandroid.so
> > (from AOSP).

I don't think it is "odd", it is simply an empty location expression,
which is defined as no location known.

> > The DW_AT_location is properly read by elfutils' dwarf_location(), but
> > is not useful for us to proceed with. Hence early exit on this.
> > 
> > 	* src/abg-dwarf-reader.cc (die_location_expr): Ignore zero
> > 	  length location expressions.
> > 	* tests/data/Makefile.am: Add new test files.
> > 	* tests/data/test-read-dwarf/test-libandroid.so: New test file.
> > 	* tests/data/test-read-dwarf/test-libandroid.so.abi: Likewise.
> > 	* tests/test-read-dwarf.cc: Add new test case.
> > 
> > Reported-by: Dan Albert <danalbert@google.com>
> > Reviewed-by: Giuliano Procida <gprocida@google.com>
> > Cc: Mark Wielaard <mark@klomp.org>
> > Signed-off-by: Matthias Maennich <maennich@google.com>

> [...]

>   // Ignore invalid location expressions where reading them succeeded but their
>   // length is 0.
>   result &= len > 0;

The actual code change looks correct, but I would like the comment to
not say they are invalid (if they were dwarf_getlocation would have
returned an error), but that an empty location expression represents an
unknown location (and so it is indeed not very useful).

See also DWARFv5 2.6.1.1.1 Empty Location Descriptions

   An empty location description consists of a DWARF expression
   containing no operations. It represents a piece or all of an object
   that is present in the source but not in the object code (perhaps
   due to optimization).

Cheers,

Mark