[BUG]: clang default dwarf version being over-ridden?

Describe the bug

Consider: https://godbolt.org/z/3Wd8q8fax

I’m trying to find which version of clang defaulted to dwarf-v5 implicitly when -g is used. I know clang switched to dwarf-v5 recently, but godbolt shows clang trunk emitting dwarf-v4 (there’s an assembler directive denoting the dwarf version in the output).

.short  4                               # DWARF version number

Steps to reproduce

enable -g for clang trunk (should be clang-16 today)

Expected behavior

.short  5                               # DWARF version number

is what I get locally for clang trunk.

Is godbolt overriding this somehow?

Reproduction link

https://godbolt.org/z/3Wd8q8fax

Screenshots

Not applicable

Operating System

No response

Browser version

No response

[nickdesaulniers]

Seems like GNU objdump can’t figure this out.

$ cat x.cpp
int square(int num) {
    return num * num;
}

int main () {
    return square(3);
}
$ g++ -g -gdwarf-5 x.cpp
$ objdump -dl a.out | grep main\>: -A 13
0000000000001138 <main>:
main():
/tmp/x.cpp:5
    1138:	55                   	push   %rbp
    1139:	48 89 e5             	mov    %rsp,%rbp
/tmp/x.cpp:6
    113c:	bf 03 00 00 00       	mov    $0x3,%edi
    1141:	e8 e3 ff ff ff       	call   1129 <_Z6squarei>
    1146:	90                   	nop
/tmp/x.cpp:7
    1147:	5d                   	pop    %rbp
    1148:	c3                   	ret
    1149:	0f 1f 80 00 00 00 00 	nopl   0x0(%rax)
$ llvm-objdump -dl a.out| grep main\>: -A 13
0000000000001138 <main>:
; main():
; /tmp/x.cpp:5
    1138: 55                           	pushq	%rbp
    1139: 48 89 e5                     	movq	%rsp, %rbp
; /tmp/x.cpp:6
    113c: bf 03 00 00 00               	movl	$3, %edi
    1141: e8 e3 ff ff ff               	callq	0x1129 <_Z6squarei>
    1146: 90                           	nop
; /tmp/x.cpp:7
    1147: 5d                           	popq	%rbp
    1148: c3                           	retq
    1149: 0f 1f 80 00 00 00 00         	nopl	(%rax)
$ clang++ -g -gdwarf-5 x.cpp
$ llvm-objdump -dl a.out| grep main\>: -A 13
0000000000001140 <main>:
; main():
; /tmp/x.cpp:5
    1140: 55                           	pushq	%rbp
    1141: 48 89 e5                     	movq	%rsp, %rbp
    1144: 48 83 ec 10                  	subq	$16, %rsp
    1148: c7 45 fc 00 00 00 00         	movl	$0, -4(%rbp)
; /tmp/x.cpp:6
    114f: bf 03 00 00 00               	movl	$3, %edi
    1154: e8 d7 ff ff ff               	callq	0x1130 <_Z6squarei>
    1159: 48 83 c4 10                  	addq	$16, %rsp
    115d: 5d                           	popq	%rbp
    115e: c3                           	retq
    115f: 90                           	nop
$ objdump -dl a.out | grep main\>: -A 13    
0000000000001140 <main>:
main():
<unknown>:5
    1140:	55                   	push   %rbp
    1141:	48 89 e5             	mov    %rsp,%rbp
    1144:	48 83 ec 10          	sub    $0x10,%rsp
    1148:	c7 45 fc 00 00 00 00 	movl   $0x0,-0x4(%rbp)
<unknown>:6
    114f:	bf 03 00 00 00       	mov    $0x3,%edi
    1154:	e8 d7 ff ff ff       	call   1130 <_Z6squarei>
    1159:	48 83 c4 10          	add    $0x10,%rsp
    115d:	5d                   	pop    %rbp
    115e:	c3                   	ret
    115f:	90                   	nop

so testing [g++, clang++] x [objdump, llvm-objdump], it seems that it is GNU objdump that doesn’t understand the output from clang++; llvm-objdump supports both compilers.

I’ve filed https://sourceware.org/bugzilla/show_bug.cgi?id=29529 against GNU objdump.

[nickdesaulniers]

This has been fixed up ToT GNU objdump. It just missed the 2.39 release, so probably whatever is after that should have the fix. Leaving this open until that release exists.