[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Error out on DW_AT_location with invalid encoding



On 07-03-19 09:27, Jakub Jelinek wrote:
> On Thu, Mar 07, 2019 at 09:23:19AM +0100, Tom de Vries wrote:
>> On 07-03-19 08:55, Jakub Jelinek wrote:
>>> On Thu, Mar 07, 2019 at 08:22:42AM +0100, Tom de Vries wrote:
>>>> Hi,
>>>>
>>>> When processing a file containing an DW_AT_location with encoding DW_FORM_addr,
>>>
>>> What kind of generator generates that?  Ugh.
>>
>> AFAICT it's the result of generating a .s file from a .c file and then
>> hand-editing the debug info (
>> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/testsuite/gdb.dwarf2/dw2-restrict.S;h=7108b86ec109ce5a1bd299e2c36696a12024e0d5;hb=HEAD
>> ):
>> ...
>>         .byte   16                      # DW_AT_stmt_list
>>         .byte   1                       # DW_FORM_addr
>> ...
> 

Hmm, I guessed it was an error introduced by hand-editing, but digging a
little further, it was in fact a generator error (clang 2.9):
https://bugs.llvm.org/show_bug.cgi?id=9995 .

> Is it worth bothering with that then?  Shouldn't just gdb be fixed?
> Or is it intentional that the test tests how it deals with invalid DWARF?
> 

I'm not sure if the test-case should be fixed. Gdb testcases are known
to contain invalid dwarf, although indeed in this case the test-case is
just to test handling of DW_TAG_restrict_type, not invalid dwarf.

> I mean, dwz has over hundred asserts and many of them will fail if fed
> complete garbage.  Do we want to turn them all into errors?

I'd propose we just fix the ones that show up with gdb testsuite (which
are just a couple), because it's a known way to test dwz.

Thanks,
- Tom