Re: dwarflint: ranges in .debug_loc vs. PCc claimed for containing DIE

[Roland McGrath <roland at redhat dot com>]

> I've implemented the test for $SUBJ, and am running into lots of 
> violations that look genuine.  Current criteria are: for each attribute 
> with loclist value (i.e. VS_location, .is_list holds) check that the 
> address ranges of that location list form a subset of PC ranges of 
> containing PC-ful DIE.

Cool.

> error: .debug_info: DIE 0x13c1: attribute `location': range [0x4014a6, 
> 0x401561) runs off DIE scope
> error: .debug_info: DIE 0x13bc: DIE scope is: [4013d4, 40155a), [4018c0, 
> 4018cf), [401db6, 401e03)

I think this error message would be clearer if it said "containing scope"
or "context" or something like that.  It took me a minute to figure out
what those two DIE offsets meant.  Perhaps take a page from the C++
compiler messages:

error: .debug_info: DIE 0x13c1: attribute `location': PC range [0x4014a6, 0x401561) outside containing scope
error: .debug_info: DIE 0x13bc: in this context: [4013d4, 40155a), [4018c0, 4018cf), [401db6, 401e03)

Except please make all the address-value outputs consistent as to whether
you use 0x or not.  (I don't really care which way it goes, but two lines
that don't match is bad.)

> So that all looks genuine--the ranges cited by dwarflint are all there 
> and they really do run off of the PC space of DIE 13bc.  I don't see how 
> to explain this other than by error of toolchain--if a variable is 
> inside a lexical_block, it's range of validity should not leak out of 
> that scope.

Agreed.  It is probably helpful in guessing the nature of the compiler bug
to cite what's obvious about the actual code at those ranges.  e.g. I'm
thinking [401561, 4014a61) could be the epilogue that immediately follows
the inlined_subroutine code, or something like that.

> There are more violations like that.  I only examined a couple, total 
> output has dozens of cases.

As a first approximation we can presume that similar-looking cases are all
the same compiler bug.  So it's enough just to thoroughly note one
representative case and then make sure we re-check the same full builds
later on when there is a compiler fix.

> I guess I'll just document this on the wiki, dunno what more to do at 
> this point.  Obviously, anyone is welcome to point out errors in my 
> reasoning above.

If this is with the F-11 or F-12 gcc, then file a Fedora bug against gcc
with a preprocessed .i file and full invocation details to reproduce the
bad output.  (This starts with picking a representative case and then
narrowing/verifying with dwarflint and/or eyeball on that .o file alone.)

I presume it will be Alex fixing those gcc bugs, be sure to put him (and
me) in the initial CC list.  An example like above might have subtleties as
to what output we really want.  You should suggest in the bug report to
discuss such details on this list rather than all in the bugzilla comments
that are harder to turn up years later in archives.

Regardless, I would very much like us to collect on the wiki a table of
known issues indexed by DW_AT_producer pattern, with pointers to the Fedora
gcc bugzilla reports (and also gcc.gnu.org bugzilla #s if those get
mentioned in Fedora bugzilla).  At some point, we can turn this into a
"quirks table" in dwarflint so it has modes to suppress complaints about
things expected from the known buggy producers.  What matters for now is
that we have a list somewhere and do not forget about any old items when
the newer compilers get fixed and stop producing them.

> How to handle these in the writer?  Should we correct this e.g. by 
> trimming location ranges to their claimed PC scope?

The writer per se should not change anything like this, i.e. anything at
the "semantic meaning" level vs pure encoding details.  To start with, I
don't want the writer even to canonicalize the semantic exact equivalents,
though we will probably do some of that later (e.g. when the location in
DW_AT_data_member_location could be replaced with a constant).  All those
kinds of transformations can be layered in later, and don't belong in the
output writer proper.  When we have those, the way to do them will be in
the dwarf_output::copier phase, i.e. transformed before they go into the
collector.  But all that's for later and for parameterized optional
features.  For now we just want semantically exact GIGO.

I don't mean to apply this to .debug_aranges, which we should generate
purely from scratch without regard to the input section.  I can also see
bending that rule for the CU itself, where it could make sense to ignore
the input DW_AT_ranges and just synthesize from the set of DIEs in the
unit.  But to start with anyway we should just use the CU's attributes as
they are.


Thanks,
Roland