Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dwarfdump mis-prints 'const' in a const pointer context #35889

Closed
pogo59 opened this issue Feb 27, 2018 · 2 comments
Closed

dwarfdump mis-prints 'const' in a const pointer context #35889

pogo59 opened this issue Feb 27, 2018 · 2 comments
Labels
bugzilla Issues migrated from bugzilla tools:llvm-dwarfdump

Comments

@pogo59
Copy link
Collaborator

pogo59 commented Feb 27, 2018

Bugzilla Link 36541
Resolution FIXED
Resolved on Sep 20, 2021 13:02
Version trunk
OS Windows NT
CC @adrian-prantl,@dwblaikie,@rnk

Extended Description

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').

@rnk
Copy link
Collaborator

rnk commented Feb 27, 2018

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;
}

@pogo59
Copy link
Collaborator Author

pogo59 commented Sep 20, 2021

Looks like @​dblaikie fixed the DWARF part of this recently, probably with
f09ca5c

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
3acdc67

At any rate, it all looks fixed now.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla tools:llvm-dwarfdump
Projects
None yet
Development

No branches or pull requests

2 participants