3 Feb
2005
3 Feb
'05
8:24 a.m.
From: Royce Mitchell III
It's my understanding that using addr2line against the
nostrip file can be off sometimes, because of subtle
differences between the two files.
I think this problem is solved now too. It was caused by the two links we
used to do, one to get file.nostrip.ext and then another one to get
file.ext. Especially when static libs were involved the second link might
produce a slightly different binary than the first.
The second link is gone now. The code and data is copied unchanged from
file.nostrip.ext to file.ext.
Also, there will be times where there are no nostrip
files,
and we may have to figure out what's going on from the files
the user is using.
If symbolic info was present in file.nostrip.ext (i.e. it was compiled with
-g, which at present implies DBG := 1), then it will also be present in
file.ext. So, the backtrace on e.g. BSODs should print the function
name/source file/source line in addition to the address. Which means we
won't have to use addr2line very often. If there was no symbolic info in
file.nostrip.ext, addr2line wouldn't be of help anyway.
But as I said, creating a util like addr2line for the final file.ext is a
piece of cake, it's just stringing together some calls to the rossym lib.
I'll create something this week.
Which brings me to my last point: I'd like to enable -g (creation of
symbolic info by the toolchain) for all builds, both DBG := 0 and DBG := 1.
The only downside I see is it will take more diskspace to build ReactOS
(currently 725 MB without symbolic info, 2477 MB with) and the final iso
will be slightly larger (13 MB instead of 10MB). Personally I think this is
outweighed by the possibility to have meaningful backtraces. Any objections?
Gé van Geldorp.