You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2003/03/07 05:46:34 UTC
I surrender (.pdb for releases, no .dbg)
After spending many hours reviewing and actively using debug symbols
for real customer incidents, I have formed some different opinions and
wanted to share.
I'm convinced that with the Win32 debugging tools (free to download)
available today, there is exactly one benefit to .dbg files - Dr. Watson
on WinNT can display backtraces. It's already possible to display
those backtraces on the 98, ME, 2k and XP from .pdb files. That small
benefit against the broken .pdb <-> binaries isn't worth that aggravation.
For me to collect the symbols from the public releases, into a symbols
store isn't possible today. The very act of rebase'ing (when extracting)
the .dbg files breaks the original association between each binary and
it's complete .pdb information file.
The .dbg files are very lightweight flavors of (with much less info than)
the comprehensive .pdb files. Anyone on WinNT can simply use WinDbg
to bring up a crash dump created by Dr. Watson. At that point, it's trivial
to look at the stack backtrace (complete with arguments) which is much
richer than Dr. Watson provides by default.
Of course a typical user won't understand either Dr. Watson or WinDbg,
but would be happy to forward a user.dmp file. The .dbg files add nothing
to what we get out of .pdb files in helping to triage such a report.
So at this point, I'm ready to back out the .dbg file creation logic, leaving
the .pdb logic for complete analysis of crash dumps of any given ASF build
of the Apache releases. Unless anyone has any objection, I should get to
this later tomorrow afternoon.
Bill
Re: I surrender (.pdb for releases, no .dbg)
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:
>Brane, I am certain you experienced an anomaly, perhaps a broken
>version of rebase.exe. I say this, having compared the sizes of the
>Apache 2.0.44 distributed iconv tree to the latest *release* build of
>the same. (Or perhaps you were looking at *debug* builds.)
>
Actually, I was looking at the apr-iconv modules linked with the static
apr and apr-iconv, not the DLLs. For some reason, rebase doesn't create
.dbg files in that case. Don't ask me why not, but there it is. So it
doesn't strip debug symbols, either.
So no, this isn't a problem for anything linked with the DLLs --
therefore, not for Apache. It is a problem for Subversion at this point
in time, but I think we can live with it for now.
>In any case, don't expect a change on the file size front, and this also
>indicates we need to quit rebasing apr-iconv, using rebase to generate
>the list of offsets and passing that list file to link (just as we do for
>libapriconv.dll and other modules.) Should be simple enough, I'll get
>to it in just a bit.
>
>Bill
>
>At 10:21 AM 3/7/2003, Branko ÄŒibej wrote:
>
>
>>This would get a big +1 from me. If I understand correctly, it would
>>also make the size of statically linked apr-iconv .so modules much
>>smaller, which is a Goodness.
>>
>>--
>>Brane ÄŒibej <br...@xbc.nu> http://www.xbc.nu/brane/
>>
>>
>
>
>
>
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: I surrender (.pdb for releases, no .dbg)
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:
>Brane, I am certain you experienced an anomaly, perhaps a broken
>version of rebase.exe. I say this, having compared the sizes of the
>Apache 2.0.44 distributed iconv tree to the latest *release* build of
>the same. (Or perhaps you were looking at *debug* builds.)
>
Actually, I was looking at the apr-iconv modules linked with the static
apr and apr-iconv, not the DLLs. For some reason, rebase doesn't create
.dbg files in that case. Don't ask me why not, but there it is. So it
doesn't strip debug symbols, either.
So no, this isn't a problem for anything linked with the DLLs --
therefore, not for Apache. It is a problem for Subversion at this point
in time, but I think we can live with it for now.
>In any case, don't expect a change on the file size front, and this also
>indicates we need to quit rebasing apr-iconv, using rebase to generate
>the list of offsets and passing that list file to link (just as we do for
>libapriconv.dll and other modules.) Should be simple enough, I'll get
>to it in just a bit.
>
>Bill
>
>At 10:21 AM 3/7/2003, Branko ÄŒibej wrote:
>
>
>>This would get a big +1 from me. If I understand correctly, it would
>>also make the size of statically linked apr-iconv .so modules much
>>smaller, which is a Goodness.
>>
>>--
>>Brane ÄŒibej <br...@xbc.nu> http://www.xbc.nu/brane/
>>
>>
>
>
>
>
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: I surrender (.pdb for releases, no .dbg)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Brane, I am certain you experienced an anomaly, perhaps a broken
version of rebase.exe. I say this, having compared the sizes of the
Apache 2.0.44 distributed iconv tree to the latest *release* build of
the same. (Or perhaps you were looking at *debug* builds.)
In any case, don't expect a change on the file size front, and this also
indicates we need to quit rebasing apr-iconv, using rebase to generate
the list of offsets and passing that list file to link (just as we do for
libapriconv.dll and other modules.) Should be simple enough, I'll get
to it in just a bit.
Bill
At 10:21 AM 3/7/2003, Branko Äibej wrote:
>This would get a big +1 from me. If I understand correctly, it would
>also make the size of statically linked apr-iconv .so modules much
>smaller, which is a Goodness.
>
>--
>Brane Äibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: I surrender (.pdb for releases, no .dbg)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Brane, I am certain you experienced an anomaly, perhaps a broken
version of rebase.exe. I say this, having compared the sizes of the
Apache 2.0.44 distributed iconv tree to the latest *release* build of
the same. (Or perhaps you were looking at *debug* builds.)
In any case, don't expect a change on the file size front, and this also
indicates we need to quit rebasing apr-iconv, using rebase to generate
the list of offsets and passing that list file to link (just as we do for
libapriconv.dll and other modules.) Should be simple enough, I'll get
to it in just a bit.
Bill
At 10:21 AM 3/7/2003, Branko Äibej wrote:
>This would get a big +1 from me. If I understand correctly, it would
>also make the size of statically linked apr-iconv .so modules much
>smaller, which is a Goodness.
>
>--
>Brane Äibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: I surrender (.pdb for releases, no .dbg)
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:
>After spending many hours reviewing and actively using debug symbols
>for real customer incidents, I have formed some different opinions and
>wanted to share.
>
>I'm convinced that with the Win32 debugging tools (free to download)
>available today, there is exactly one benefit to .dbg files - Dr. Watson
>on WinNT can display backtraces. It's already possible to display
>those backtraces on the 98, ME, 2k and XP from .pdb files. That small
>benefit against the broken .pdb <-> binaries isn't worth that aggravation.
>
>For me to collect the symbols from the public releases, into a symbols
>store isn't possible today. The very act of rebase'ing (when extracting)
>the .dbg files breaks the original association between each binary and
>it's complete .pdb information file.
>
>The .dbg files are very lightweight flavors of (with much less info than)
>the comprehensive .pdb files. Anyone on WinNT can simply use WinDbg
>to bring up a crash dump created by Dr. Watson. At that point, it's trivial
>to look at the stack backtrace (complete with arguments) which is much
>richer than Dr. Watson provides by default.
>
>Of course a typical user won't understand either Dr. Watson or WinDbg,
>but would be happy to forward a user.dmp file. The .dbg files add nothing
>to what we get out of .pdb files in helping to triage such a report.
>
>So at this point, I'm ready to back out the .dbg file creation logic, leaving
>the .pdb logic for complete analysis of crash dumps of any given ASF build
>of the Apache releases. Unless anyone has any objection, I should get to
>this later tomorrow afternoon.
>
>
This would get a big +1 from me. If I understand correctly, it would
also make the size of statically linked apr-iconv .so modules much
smaller, which is a Goodness.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/