Hi Joseph,
> I still have no idea from your answer how a user is meant to know whether
> to use the option when compiling, linking or both, which is what needs to
> be clear from invoke.texi.
>
> What does it mean for the option to be supported for compiling but not
> linking? What in that case will the linker do with compressed debug
> sections on input? Combine them in some way, good or bad? Uncompress
> them?
a linker that doesn't understand compressed debug sections will probably
combine them in a useless way. If, like gld, it can read but not write
them, they will be written in uncompressed form.
> Likewise, for it to be supported for linking but not compiling? Will the
> linker then compress the uncompressed sections it receives on input?
Yes, that will work in all cases.
> I think it would be better if the option semantics are more like "if you
> pass the same option when both compiling and linking, the linked output
> will have the sections appropriately compressed as specified by the
> option, whether or not the individual .o files do" - and if this can't be
> supported with the tools being used, don't allow the option.
That's certainly an option, as in the following table (taking the
zlib-gnu format as an example, but omitting hypothetical linkers that
can write but not read compressed debug sections):
assembler linker action example
w r w
- - - reject as/ld
- x - reject, useless as/gld
- x x ok, warn about no-op as -gz? as/gold
x - - reject, harmful gas/ld
x x - reject, useless gas/gld
x x x ok gas/gold
The only problem I see is that for an assembler not supporting
compression -gz would be a silent no-op. I'd rather warn about this
instead, but still accept it so you can both compile and link with -gz.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
