https://sourceware.org/bugzilla/show_bug.cgi?id=30588
--- Comment #1 from Indu Bhagat <indu.bhagat at oracle dot com> --- What is the incentive to support --disable-libsframe ? Currently, the GNU ld, objdump, readelf use libsframe to read/write/dump SFrame data. Thinking aloud about this would imply. The SFrame section (.sframe) is generated by the assembler (unlike CTF which is generated by the compiler). If BFD's dependency on libsframe is to be made optional, then it leaves the set of binary utilities in a fuzzy state I think: assember continues to generate .sframe when provided with --gsframe, but the linker errors out that its built with no sframe support ? or does it quietly remove them? Because it cannot possibly merge them correctly if built with --disable-libsframe. Now there is also some SFrame stack trace data generated by the linker for the dynamic sections on x86_64 (.plt, .plt.sec etc). All of the latter will also need to be guarded somehow... I'd say in terms of functionality SFrame is close to .eh_frame, rather than CTF. The advantage of separating out the reader/writer APIs of SFrame data into a library of its own is that potentially other components in the future can use it. Perhaps other linkers. -- You are receiving this mail because: You are on the CC list for the bug.