mstorsjo abandoned this revision.
mstorsjo added a comment.
Herald added a subscriber: chrib.
FWIW, I'm not going to put any more effort into this one at the moment, I
managed to fix my use case in a much simpler way by providing a Windows Store
compatible version of EnumProcessModules, see
joerg added a comment.
The "struct object" is an implementation detail of the unwind implementation.
You are guaranteed historically to get at least 8 longs / 8 pointers for
internal use statically allocated in each object. What is stored inside is up
to the unwind implementation.
mstorsjo updated this revision to Diff 140410.
mstorsjo edited the summary of this revision.
mstorsjo added a comment.
Herald added a subscriber: JDevlieghere.
Added and using a helper function `isCIE` to avoid using the error return path
from `decodeFDE`.
Technically, the decision between a
mstorsjo added a subscriber: joerg.
mstorsjo added a comment.
Also, relating to this, @joerg mentioned on irc that one should rather use
`__register_frame_info_bases` instead of `__register_frame`. That function is a
bit tricky to call though, since it uses a libgcc internal struct `struct
mstorsjo added a comment.
In https://reviews.llvm.org/D44494#1050803, @mstorsjo wrote:
> In https://reviews.llvm.org/D44494#1050797, @mstorsjo wrote:
>
> > This else clause isn't about `.eh_frame` vs `.eh_frame_hdr`, but about
> > registering a single FDE (which libunwind's `__register_frame`
mstorsjo added a comment.
In https://reviews.llvm.org/D44494#1050797, @mstorsjo wrote:
> This else clause isn't about `.eh_frame` vs `.eh_frame_hdr`, but about
> registering a single FDE (which libunwind's `__register_frame` currently
> does) vs registering a full `.eh_frame` section (which
mstorsjo added a comment.
In https://reviews.llvm.org/D44494#1050783, @compnerd wrote:
> I really don't like this approach. I think that we should introduce a
> different entry point for this behavior rather than saying that we go through
> the existing interface. Having a reference to the
compnerd requested changes to this revision.
compnerd added a comment.
This revision now requires changes to proceed.
I really don't like this approach. I think that we should introduce a
different entry point for this behavior rather than saying that we go through
the existing interface.
mstorsjo updated this revision to Diff 138451.
mstorsjo added a comment.
Avoid using the C++ header.
https://reviews.llvm.org/D44494
Files:
src/UnwindCursor.hpp
src/libunwind.cpp
Index: src/libunwind.cpp
===
---
mstorsjo added inline comments.
Comment at: src/UnwindCursor.hpp:53
unw_word_t fde, unw_word_t mh));
+ static void iterateSections(std::function func);
rnk wrote:
> I'm concerned that std::function might
rnk added inline comments.
Comment at: src/UnwindCursor.hpp:53
unw_word_t fde, unw_word_t mh));
+ static void iterateSections(std::function func);
I'm concerned that std::function might introduce runtime
mstorsjo created this revision.
mstorsjo added reviewers: rnk, compnerd.
Previously, the __register_frame function supported registering an FDE for one
individual function at a time. The function could also be used registering a
full .eh_frame section of a module (which is how libgcc sets up
12 matches
Mail list logo
