[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210717133825.07eae84e@vostro>
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.
