LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 36541 - dwarfdump mis-prints 'const' in a const pointer context
Summary: dwarfdump mis-prints 'const' in a const pointer context
Status: RESOLVED FIXED
Alias: None
Product: tools
Classification: Unclassified
Component: llvm-dwarfdump (show other bugs)
Version: trunk
Hardware: PC Windows NT
: P enhancement
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-27 10:39 PST by Paul Robinson
Modified: 2021-09-20 13:02 PDT (History)
4 users (show)

See Also:
Fixed By Commit(s):

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Robinson 2018-02-27 10:39:14 PST 
Mentioned in passing in bug 36526 but deserving its own report:
llvm-dwarfdump prints the 'const' before the unqualified type name,
which is syntactically incorrect if the unqualified type name is a
pointer.  I didn't check but likely any other qualifier would have
the same problem (certainly 'volatile' and probably _Atomic or
however that one is spelled).



$ cat t.cpp
int i = 1;
const int j = 2;
int * const const_ptr_to_int = &i;
const int * ptr_to_const_int = &j;

int foo() {
  return *const_ptr_to_int + *ptr_to_const_int;
}
$ clang -c -g t.cpp
$ llvm-dwarfdump -debug-info t.o
...
0x00000046:   DW_TAG_variable
                DW_AT_name	("ptr_to_const_int")
                DW_AT_type	(cu + 0x005b "const int*")
...
0x00000065:   DW_TAG_variable
                DW_AT_name	("const_ptr_to_int")
                DW_AT_type	(cu + 0x0070 "const int*")
...



Entertainingly, "const int * const foo" comes out as "const const int*".

I could see wrapping the qualified type in parens, or just printing the
qualifier after the referenced type.  This means non-pointer types
would have the 'const' appearing on the right, which is a style favored
by some ('int const' rather than 'const int').
Comment 1 Reid Kleckner 2018-02-27 12:56:07 PST 
llvm-readobj -codeview has the same problem. I checked the code because I thought we had fancy logic to get this right, but it turns out that we do not.

This is how we print the globals:
    GlobalData {
      Kind: S_GDATA32 (0x110D)
      DataOffset: ?i@@3HA+0x0
      Type: int (0x74)
      DisplayName: i
      LinkageName: ?i@@3HA
    }
    GlobalData {
      Kind: S_GDATA32 (0x110D)
      DataOffset: ?ptr_to_const_int@@3PEBHEB+0x0
      Type: const int* (0x1004)
      DisplayName: ptr_to_const_int
      LinkageName: ?ptr_to_const_int@@3PEBHEB
    }
    DataSym {
      Kind: S_LDATA32 (0x110C)
      DataOffset: j+0x0
      Type: const int (0x1003)
      DisplayName: j
      LinkageName: j
    }
    DataSym {
      Kind: S_LDATA32 (0x110C)
      DataOffset: const_ptr_to_int+0x0
      Type: const int* (0x1005)
      DisplayName: const_ptr_to_int
      LinkageName: const_ptr_to_int
    }

I had to modify the test case like this to force us to emit both globals:

int foo() {
  return **&const_ptr_to_int + *ptr_to_const_int;
}
Comment 2 Paul Robinson 2021-09-20 13:02:16 PDT 
Looks like @dblaikie fixed the DWARF part of this recently, probably with
f09ca5c6461b604113b6e1adb825be2d92575aff

As for the CodeView part, it's working for me; the commit logs suggest that
it might have been as long ago as D43060 committed as
3acdc6773444b0dea84a69e99024e07ebabc0c98 

At any rate, it all looks fixed now.