Re: [PATCH] gold: add incremental input structures definitions

[Ian Lance Taylor <iant at google dot com>]

Mikolaj Zalewski <mikolajz@google.com> writes:

>   This patch adds some of the structures needed by incremental
> linking. It has no effect yet, but I wanted to show it already. I have
> chosen the next available SHT_ - is it OK, or should they be chosen
> with care?

Does anybody else have an opinion on this one?  I know that Solaris is
already using the same values that we are.  Should we try to register
the section type to use for incremental linking information?


> As the incremental linking is specific to our linker, the
> structures should go to gold/, or should they go to elfcpp/?

I think putting them in gold is fine.


>   If I understand, the design assumes that the command line is stored
> as one string. Wouldn't it be easier to store it as a vector of
> strings? This could make it easier to remove the --incremental-*
> options.

In the data stored in the file, I see no advantage to using a vector of
strings.  That will just take additional space without providing any
benefit.



> 2009-02-27  Mikolaj Zalewski  <mikolajz@google.com>
>
> 	* elfcpp/elfcpp.h: Add SHT_GNU_INCREMENTAL_INPUTS
> 	* gold/Makefile.in: Add incremental.cc
> 	* gold/Makefile.am: Add incremental.cc
> 	* gold/incremental.cc: New file
> 	* include/elf/common.h: Add SHT_GNU_INCREMENTAL_INPUTS

These entries would go in different files, and the file names would be
adjusted accordingly.  They should say which part of the file is
changed.  For example:

	* elfcpp.h (SHT_GNU_INCREMENTAL_INPUTS): Define.

	* incremental.cc: New file.
	* Makefile.am (CCFILES): Add incremental.cc.
	* Makefile.in: Rebuild.

Ian