Michael137 added a comment. In D144999#4417731 <https://reviews.llvm.org/D144999#4417731>, @oontvoo wrote:
> In D144999#4415419 <https://reviews.llvm.org/D144999#4415419>, @oontvoo wrote: > >> In D144999#4415137 <https://reviews.llvm.org/D144999#4415137>, @jasonmolenda >> wrote: >> >>> Michael and I looked into this. This simple c++ file is resulting in >>> eh_frame unwind info on aarch64 darwin instead of compact unwind info. > > P.S: still no luck reproducing this with TOT clang. Would you mind verifying > my test case below (this was on M1 <https://reviews.llvm.org/M1> mac): > > ### clang is built with commit up to > 5b1c62c0f2e9a739707429f650cb897c067f86c2 > vyng-macbookpro3 /Users/vyng/repo/llvm-project/build_all$ ./bin/clang++ > ../cross-project-tests/debuginfo-tests/dexter-tests/optnone-struct-and-methods.cpp > -g -O0 -c -o test_tot.o > > vyng-macbookpro3 /Users/vyng/repo/llvm-project/build_all$ objdump --macho > --unwind-info --dwarf=frames test_tot.o > Contents of __compact_unwind section: > Entry at offset 0x0: > start: 0x0 ltmp0 > length: 0x70 > compact encoding: 0x44000000 > personality function: 0x0 ___gxx_personality_v0 > LSDA: 0x238 ltmp1 > Entry at offset 0x20: > start: 0x70 __ZN12_GLOBAL__N_11AC1Ev > length: 0x2c > compact encoding: 0x04000000 > Entry at offset 0x40: > start: 0x9c __ZN12_GLOBAL__N_11A7getDataEv > length: 0x78 > compact encoding: 0x04000000 > Entry at offset 0x60: > start: 0x114 __ZN12_GLOBAL__N_11AD1Ev > length: 0x2c > compact encoding: 0x04000000 > Entry at offset 0x80: > start: 0x140 __ZN12_GLOBAL__N_11AC2Ev > length: 0x2c > compact encoding: 0x02001000 > Entry at offset 0xa0: > start: 0x16c __ZN12_GLOBAL__N_11A12setOtherDataEv > length: 0x74 > compact encoding: 0x04000000 > Entry at offset 0xc0: > start: 0x1e0 __ZN12_GLOBAL__N_11A12getOtherDataEv > length: 0x18 > compact encoding: 0x02001000 > Entry at offset 0xe0: > start: 0x1f8 __ZN12_GLOBAL__N_11AD2Ev > length: 0x40 > compact encoding: 0x04000000 > > .debug_frame contents: > > > .eh_frame contents: > <<<< nothing in eh_frame section, which is expected and matches what > produced by base clang Sorry for the back-and-forth Looks like D152540 <https://reviews.llvm.org/D152540> did indeed resolve this. The bots apparently didn't pick that change up until today. And locally I must've been producing the binary without that commit It's all good now, thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D144999/new/ https://reviews.llvm.org/D144999 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits