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.
One violator is src/size form elfutils:
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)
DWARF section [29] '.debug_info' at offset 0x34c5: [Offset] Compilation unit at offset 0: Version: 2, Abbreviation section offset: 0, Address size: 8, Offset size: 4 [ b] compile_unit producer "GNU C 4.4.1 20090725 (Red Hat 4.4.1-2)" language ISO C99 (12) name "../../elfutils/src/size.c" comp_dir "/home/petr/proj/elfutils/dwarflint/build/src" low_pc 0x0000000000401050 <print_version> high_pc 0x0000000000402429 stmt_list 0 [ 125b] subprogram name "handle_elf" decl_file 1 decl_line 667 prototyped low_pc 0x0000000000401320 <handle_elf> high_pc 0x0000000000401ed0 <handle_ar> frame_base location list [ 320] sibling [ 16ae] [ 1390] inlined_subroutine abstract_origin [ 11a9] entry_pc 0x00000000004013d4 <handle_elf+0xb4> ranges range list [ 280] call_file 1 call_line 692 sibling [ 1439] [ 13bc] lexical_block ranges range list [ 2c0] [ 13c1] variable abstract_origin [ 11e7] location location list [ 74c]
(In following, the values on the right match those on the left after adding CU's low_pc.)
DWARF section [34] '.debug_ranges' at offset 0x7771: [ 2c0] 0x0000000000000384..0x000000000000050a 0x4013d4 0x40155a 0x0000000000000d66..0x0000000000000db3 0x401db6 0x401e03 0x0000000000000870..0x000000000000087f 0x4018c0 0x4018cf
DWARF section [33] '.debug_loc' at offset 0x6209: [ 74c] 0x00000003d9..0x0000000456 [ 0] reg13 0x401429 0x4014a6 0x0000000456..0x0000000511 [ 0] reg12 0x4014a6 0x401561 0x0000000870..0x000000087f [ 0] reg12 0x4018c0 0x4018cf 0x0000000d66..0x0000000db3 [ 0] reg13 0x401db6 0x401e03
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.
There are more violations like that. I only examined a couple, total output has dozens of cases.
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.
How to handle these in the writer? Should we correct this e.g. by trimming location ranges to their claimed PC scope?
Thanks, PM
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
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
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.
There is no need to get it fixed in F-11. It might be worth having it reported somewhere just to document it fully, especially if the current compiler can still produce it with -fno-var-tracking-assignments.
Added it among SuspiciousDebuginfoCases. It's the first reasonably documented case on that site, with reproducer and dumps.
Cool. Having it there seems like enough to point Alex at just to be sure he's cognizant, if it notes that -fno-var-tracking-assignments changed it and the old behavior might be lurking in the other mode. (Just a link to this archived discussion is enough for that.)
Thanks, Roland
elfutils-devel@lists.fedorahosted.org