I'm currently in the process of developing a more useful
exceptionhandler for our project (Warzone 2100 ). I'm basically
taking exchndl.c from Dr. MinGW's exception handling DLL (exchndl.dll)
and will extend that further where necessary.
I've started work on this by first trying to compile exchndl.c without
modifications and linking it statically into the project.
At first compiling failed due to what, according to some Googling, was a
misplaced parenthesis. This was fixed easily enough . (Google was
faster than manually trying to find out all of the types of every struct
I then got linker errors when linking with libbfd because of two missing
symbols: bfd_get_section_size_before_reloc and
bfd_get_section_size_after_reloc. In these same threads I found for the
above compiler error I also found a simple fix .
Now I could get exchndl.c to compile and link fine with the libbfd and
libiberty shipped with MinGW.
However, when I inserted some test code to trigger segfaults:
> int* i = 0; *i = 27;
I discovered that my self-compiled failed to extract symbols for the
generated stack dump. This unlike the precompiled exchndl.dll that is
shipped with mingw-utils 0.3 which does this successfully. Compiling
exchndl.c as a DLL had the same results as linking statically (i.e. no
symbols in the stack trace).
After yet some more Googling I found a thread on this mailing list which
seems to deal with the same issue (i.e. the symptoms are the same at
Like his case I traced the problem to the function
find_address_in_section in exchndl.c. Unlike his case, however, I
discovered that in my case bfd_find_nearest_line never even got called.
In my case the function already returned on this if-statement:
> if (info->pc >= vma + (size = bfd_get_section_size_before_reloc (section)))
Apparently __all__ return addresses on the stack are larger than (vma +
size). Which lead me to look at vma's value, which apparently __always__
is zero (vma = 0) for me. Then after scanning the BFD documentation I
found out that the vma represents the virtual memory's base address.
This obviously shouldn't be zero on any modern OS, thus I assume
something went wrong in computing this vma.
The precompiled DLL, however, __does__ work, thus I would like to know
if and how this DLL is different from the source code provided. Aside
from that the only thing I can think of is that the versions of libbfd
that DLL has been linked against and the version I am using to link to
(version shipped with the MinGW-5.1.3 installer) might differ. This
would also explain the above mentioned linker errors.