[cfe-dev] Porting libcxxabi / Unwind to Windows / MingW 32 bit

Yaron Keren yaron.keren at gmail.com
Wed Oct 30 15:03:30 PDT 2013


Hi Nick,

I looked at the disassembly, unw_getcontext() gets the correct IP into the
context and later setInfoBasedOnIPRegister gets it right into "pc". This is
OK.

The trouble is, the whole address space is nowhere near the fde values. For
example,

p =          0x66179070
<libunwind::DwarfFDECache<libunwind::LocalAddressSpace>::_initialBuffer>
pc =         0x6604e7d9
fde =         0x40801c0
p->ip_start = 0x4080010
p->ip_end =   0x408010c

p is consistent with pc and local vars and addresses in unwind.dll
(0x66YYYYYY)
fde is consistent with the ip ranges and with the caller of unwind.dll (the
throwing function) address space (0x40800YY)

they live in different memory ranges, the fde addresses are in caller range
whereas the unwind addresses are in the DLL range so when it tries to find
its IP in the fde tables it can't find.

It's as if the DLL is supposed to load in other memory range, some linker
option required?

Yaron



2013/10/29 Nick Kledzik <kledzik at apple.com>

>
> On Oct 29, 2013, at 12:11 AM, Yaron Keren <yaron.keren at gmail.com> wrote:
>
> > Hello,
> >
> > I'm trying to make libcxxabi / Unwind work on Windows / MingW 32 bit.
> Attached is a patch to make it compile without warnings and run without
> crashing.
> >
> > However the functionality isn't working yet: upon exception, the IP
> seems to be completely out of range the FDE tables. This may be related to
> the memory model / compilation options???
> Take a look at UnwindRegisterRestore.s.  When an exception is thrown,
> unw_getcontext() is called which saves all registers and the return address
> into a register struct.  Then the FDE info is used to step through each
> frame and modify the register set.  At which step is the IP register out of
> bounds?
>
> It might be that the C files need to be compiled with -fexceptions so that
> they have unwind tables.
>
> -Nick
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131031/9f36cd68/attachment.html>


More information about the cfe-dev mailing list