Re: [Mingw-users] exchndl.c (mingw-utils)

[David F. <da...@sj...>]

Serge Semashko wrote:

> Hello All,
>
> I have tried to use exchndl.c from mingw-utils for automated error 
> reporting in a program on crashes with a stack backtrace.
>
> Readme file states that it works when the executable has debugging 
> information. But debugging information explodes the size of the 
> program too much (1.7MB stripped executable, 2.5MB executable with 
> symbols, 7.5MB executable with debugging information). That's not very 
> good.
>
> The problem is that exchndl.c can't use symbol table for resolving 
> function names. Looks like the problem is in bfd_find_nearest_line 
> function. It always returns false. Googling for this problem I have 
> found the following message:
> http://mail.gnu.org/archive/html/bug-gnu-utils/2003-05/msg00140.html
> Maybe bfd_find_nearest_line it is not working with mingw because of a 
> similar problem (unsorted symbols)?
>
> I have hacked exchndl.c code and replaced a call to 
> bfd_find_nearest_line by walking though symbol table in a loop, now it 
> seems to work for my purpose (though I have broken a lot of other 
> things and there is nothing to contribute back to mingw-utils back 
> yet). This my modified code is available here:
>
> http://lxnt.info:8888/repos/ufo2k/trunk/src/exchndl/
>
> Is there anything that can be done to make bfd_find_nearest_line 
> function work properly and mingw-utils to support extracting the 
> information from symbol table? 

We have a modified version of exchndl.c that we use that just records 
the stack traces and doesn't do function name lookup (so we don't have 
to link to bfd which is GPL). Then we run a python script afterwards 
that looks up the function names.
This allows us to send a stripped executable to a customer, get a stack 
trace, and see exactly what it said.

David