06.10.2009 22:47, Roland McGrath wrote:
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.
Thanks, re-phrased and made the code use range formatting function.
> 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.
I cut the source down to a trivial reproducer, and the range claims a
nop used for alignment mid-block.
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.)
That was F-11 gcc. I built gcc 4.4.1-19, which should end up in F-12.
That has VTA back-ported and does not reproduce the bug. I wonder
whether to report the bug when the new version fixes it anyway.
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
Added it among SuspiciousDebuginfoCases. It's the first reasonably
documented case on that site, with reproducer and dumps.
Thanks,
PM