This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Code Bloat g++
- To: pfeifer at dbai dot tuwien dot ac dot at
- Subject: Re: Code Bloat g++
- From: "Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>
- Date: Fri, 18 Feb 2000 22:17:48 +0100
- CC: jbuck at possibly dot synopsys dot com, gcc at gcc dot gnu dot org
- References: <Pine.GSO.4.21.0002181318050.28706-100000@nunki.dbai.tuwien.ac.at>
> Consider one of my .s files generated with GCC 2.95.2 with -O -g. The
> following random snippet is not an exception there, it is common! :-(
I've considered it. However, from my (probably shallow) analysis, it
seems that every line below is necessary.
> .stabn 192,0,0,.LLBB51616-CreatePTs__11HeuristicPT
> .stabn 192,0,0,.LLBB51617-CreatePTs__11HeuristicPT
> .stabn 224,0,0,.LLBE51617-CreatePTs__11HeuristicPT
> .stabn 224,0,0,.LLBE51616-CreatePTs__11HeuristicPT
For example, this means there is a lexical block starting at
.LLBB51617, going up to .LLBE51617. Around this block, there is
another block going from .LLBB51616 to .LLBE51616
> That is definitely not very compact and it's well possible that the
> project you mentioned experiences the same problem.
Maybe you've been confused by the fact that '192' and '224' above are
specific debugging constants, indicating LBRAC and RBRAC, so these
lines (and all the others) are certainly not meaningless.
Also, in the object file, each line translates to a 16-byte block: The
expressions '.LLBB51616-CreatePTs__11HeuristicPT' are evaluated by the
assembler, and don't appear there as text - so it is only in the
assembler file that you have to deal with the mangled names of
functions; to get the relative offset in the function.
Now, of course, I'm somewhat confused that this bracketing is included
in the debug information. I'd guess that the original function
(i.e. HeuristicPT::CreatePTs(void)) indeed contains as many left and
right brackets, as indicated above.
From looking at binutil's stab.def, one purpose of left and right
bracket indication is to explain visibility of local variables to the
debugger. The local variables would normally precede the LBRAC, and
would be indicated by a stabs 128 (LSYM). In this case, they certainly
don't serve this purpose - the blocks in questions don't have any
locals.
Perhaps the LBRAC and RBRAC records serve an additional purpose even
in absence of any local variables? Or, would it be possible to
eliminate these records of there are no automatic variables in a
block? Any comments appreciated.
Regards,
Martin