From: Serge S. <ss...@vb...> - 2004-05-25 07:47:59
|
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? |
From: Heiko G. <hg...@te...> - 2004-05-25 10:55:52
|
On Tuesday 25 May 2004 09:48, 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. [snip] > > 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? I have no answer for the particular bfd_find_nearest_line problem but some other suggestions: I usually keep an objectdump of any released version. You could than retrieve the code line from the backtrace adress and the objdump. Locally you could use Dr.Mingw (if Debugging information is available of course). And note: Using exchndl with bfd requires the GPL Licence model. Greetings Help |
From: David F. <da...@sj...> - 2004-05-25 11:56:19
|
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 |