[LLDB][ELF] LLDB gets confused if there are multiple .text sections in a binary

[al45tair]

I had a Swift PR open (swiftlang/swift#72061) that changes how Swift handles the metadata sections (in particular), but as a consequence causes the compiler to set SHF_GNU_RETAIN on other sections as well. At time of writing, all of the tests are passing except some LLDB API tests, which was very puzzling.

The problem appears to be that, because of the behaviour of older versions of ld.gold (prior to binutils 2.36), libswiftCore.so ends up with two .text sections, and then when LLDB tries to print a Swift object, it attempts to call Swift._DebuggerSupport.stringForPrintObject, but gets mixed up and adds the offset it found for that function to the wrong .text section, jumps into the end of an entirely unrelated function and (eventually) crashes after triggering an assertion failure.

The bug here is that LLDB appears to get confused about the presence of two .text sections, which leads to symbol lookups going awry.

I've attached a small reproducer, which doesn't need Swift (or anything to do with Swift).

lldb-two-text-sections.tar.gz

(We're tracking this internally as rdar://124467787.)

[llvmbot]

@llvm/issue-subscribers-lldb

Author: Alastair Houghton (al45tair)

I had a Swift PR open (https://github.com/swiftlang/swift/pull/72061) that changes how Swift handles the metadata sections (in particular), but as a consequence causes the compiler to set `SHF_GNU_RETAIN` on other sections as well. At time of writing, all of the tests are passing *except* some LLDB API tests, which was very puzzling.

The problem appears to be that, because of the behaviour of older versions of ld.gold (prior to binutils 2.36), libswiftCore.so ends up with two .text sections, and then when LLDB tries to print a Swift object, it attempts to call Swift._DebuggerSupport.stringForPrintObject, but gets mixed up and adds the offset it found for that function to the wrong .text section, jumps into the end of an entirely unrelated function and (eventually) crashes after triggering an assertion failure.

The bug here is that LLDB appears to get confused about the presence of two .text sections, which leads to symbol lookups going awry.

I've attached a small reproducer, which doesn't need Swift (or anything to do with Swift).

lldb-two-text-sections.tar.gz

(We're tracking this internally as rdar://124467787.)

[al45tair]

I found another fun symptom of the same problem. If you set a breakpoint on main and then let the child program run, if you're afflicted with the two .text sections problem, it's possible the program will stop at __start unexpectedly. (If you check the breakpoints that were created, there will be one pointing at __start!)

This happens because main ends up at the start of one of the .text sections, while __start is at the start of the other. LLDB then gets confused and installs an additional breakpoint because it finds both main in the proper place (via the debug information) and main but with the wrong section (via the symbol table).