[PATCH] Symbol Separation - Take 2

Gerald Pfeifer gerald@pfeifer.com
Thu Jul 17 11:35:00 GMT 2003


Thanks for the updated patch and the add documentation.

I'm not a native speaker, but there seem to be quite a couple of issues
with the documentation.  Below I'm trying to help with some of them, but
I think it would be best if some technical writer or fellow developer at
Apple could have another look as well.

On Mon, 14 Jul 2003, Devang Patel wrote:
> This patch is same as previous patch. Only difference is in
> documentation.

+ @item -grepository
+ @opindex grepository
+ Instructs compiler to find and validate symbol repository available
+ in include paths.

"Instructs the compiler to..."

Though, perhaps just "Consider symbol repositories available..."?

"symbol repositories" (Plural) ?

+ @item -fsave-repository=@var{location}
+ @opindex fsave-repository
+ Creates a separate symbol repository at @var{location} for given input
+ header file.

Again, _how_ is that input header file given? Note that this sentence
states that there is just a single such file.

+ This new separate repository contains only debugging symbols.

Omit separate.

+ In a typical large project, every source file includes very large
+ headers. Usually such large headers do not change frequently but
+ they add their overhead in standard compile-link-debug cycle. As

"...but still add overhead to the standard compile-link-debug cycle..."

+ far as debugging information is concerned, it adds overheads in
+ 4 steps:

"overhead" (singular)

+ (1) GCC has to generate redundant debugging information for types
+     while compiling every source file.
+ (2) GCC has to dump this redundant info in .s files.
+ (3) Assembler has to chew more bytes and emit bigger .o files.
+ (4) Linker has to chew more bytes and do more work to reduce redundant
+     info.

I don't think this will show up properly in info or DVI formats.

"The assembler has to process larger input and emits bigger
@file{.o} files."

"The linker has to process larger input and reduce redundant information."

+ In many cases precompiled header (@pxref{Precompiled Headers}) helps to
+ reduce step(1) overhead.

"precompiled headers...help...to reduce the overhead from item (1) above."

+ In this new model, symbol repositories containing debugging informations
+ are created in advance.

"information" (singular)

+ While compiling source files, GCC consults these
+ repositories before generating debugging information for each header and
+ avoids redundant debugging info.

Omit "while compiling source files"?

+ It is user's responsibility to supply
+ these repositories (they are simple .o files) to link editor so that
+ final image contains all debugging information.

"It is the user's"
"@file{.o}"
"to the link editor"
"the final image"

+ This creates two files.
+ (1) MyHeader.h.o: Object file with debugging info. This is created
+     in current working directory or its name and location can be
+     controlled using -o option. User needs to supply this file to
+     link editor during linking.

"@file{MyHeader.h.o}, an object file with debugging info."
"the current..."
"The user"
"the link editor" and omit "during linking".

+ (2) MyHeader.cinfo: Context info file to validate MyHeader.h.o. It
+     will be created in /my_ss/ directory.

@file{/my_sss/}

"in the...directory"

+ This file contains context information for header. GCC uses it to
+ validate symbol repository.

Something is wrong with "for header".

"...which GCC uses to...the symbol respository."

+ To use repository

"the repository"

+ Current implementation works with STABS debugging format only.

"The current implementation supports the STABS debugging format only."

+ It is
+ recommonded to make symbol repository before making precompiled header.

typo

"making" doesn't seem right.

+ See @option{-grepository} for more information.

Gerald



More information about the Gcc-patches mailing list