Date: Sat, 17 Jul 2021 13:38:25 +0300 From: Timo Teras <timo.teras@....fi> To: Rich Felker <dalias@...c.org> Cc: musl@...ts.openwall.com Subject: Re: option to enable eh_frame On Sat, 17 Jul 2021 10:33:38 +0300 Timo Teras <timo.teras@....fi> wrote: > On Fri, 16 Jul 2021 11:57:35 -0400 > Rich Felker <dalias@...c.org> wrote: > > > You can solve this problem just as well for the things you want to > > have work by including the (part of) the debug info you want in the > > main libc.so binary: .debug_frame. > > For me it's quite unusual to have .debug_frame but not other debug > sections. I assume it works. But the tooling certain does not endorse > this setup. I suppose it can be achieved with some objcopy magic, but > requires care. I'm investigating this. And seems that "strip -g --keep-section=.debug_frame" works after all. I remember objcopy often not doing what wanted, but happily this is doable in a simple enough way. However, there actually is some reasons why .eh_frame that goes to LOAD phdr is helpful. That is core dump (when all of the mapped memory is dumped). This allows easy investigation of crashed program state with proper tooling even if none of the debug info is available. .debug_info would not go there because it's not mapped. Granted, the above is a bit of rare condition and probably not of huge importance for many. But I do use it regularly. Another difference is that there's no .eh_frame_hdr equivalent which allows binary searchable tree based on PC. But then again, this is mostly useful for backtrace() style usage. External stuff like debuggers and profilers etc. can build this runtime if needed - it just is a small (hopefully onetime) extra performance hit. I think just keeping .debug_frame would solve the problems I'm having (modulo the core dump case). But since the backtrace() and other things are also involved, I hope we could have a proper discussion on the technical side. And also consider if "the badness" could be made "bad" (by crashing or similar) even if including .eh_frame. Speaking of this, I'm wondering how many C-library functions can call callbacks? Another approach would be to arm these functions with __attribute__((cleanup())) where the clean up crashes if called via unwind. Probably bad idea extra work wise, but would make it very obvious unconditionally that unwinding C-functions is not wanted. Makes one hope gcc had a way to insert personality function to crash on unwind attempt... Also, what if the code base is compiled with frame-pointers enabled? Does that make unwinding work even without eh_frame? Is the "-fomit-frame-pointer" vs. "-fno-omit-frame-pointer" affecting current perceived "contract"? Timo
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.