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
htt
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.
https://rev
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 ful
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
obje
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` cu
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 lib
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. Havi
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
===
--- src/libunwind
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 introduc
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 dependen
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 unw
12 matches
Mail list logo
