SPARC gold / ld support

[Jorge Pérez]

Hoping no to bother I wanted to still explore an option of the linker,
the "--print-map" which outputs valuable linking information. My
question therefore is, is there a way the linker accepts such map as
input?

What I was thinking about is: 1) manage to strip the SETHIs using some
home-made script, 2) modify "the" linking map if such thing is
possible, and 3) feed it to the linker. In such way I was expecting to
have a still working executable with several sethi instructions
removed.

What do you think?

Thanks in advance for your time and your patience :)


Jorge

2010/1/19 Ian Lance Taylor <iant@google.com>:
> Jorge Pérez <jernestop@gmail.com> writes:
>
>> I'm looking forward to implement the SPARC V8 for an embedded
>> application and since I have very limited memory resources, I'm
>> interested in obtaining the best possible code density. I'm wondering
>> if with these regards is there a remarkable difference between LD and
>> GOLD?
>
> The gold linker is intended to be faster than the GNU linker but is
> otherwise more or less compatible for normal use.  That said, using a
> linker script slows gold down a lot.
>
>
>> Besides, given the hard constraints of my target, I do not need / care
>> about the code being position independent (PIC). In fact, I
>> intentionally located the .rodata section of my programs at 0x00000000
>> so the high22 bits of the SETHI instructions pointing at .rodata are
>> set to 0. This, in principle, would let me get rid of most SETHI
>> instructions, or at least those pointing to the .rodata section for
>> instance. As an example, I can reduce the code size of a Paranoia
>> bench by 19% which is huge in the embedded context. However I do not
>> know if such modification is feasible / possible / already implemented
>> at the linker level (ld, gold?).
>
> The linkers are not going to be able to remove sethi instructions for
> you.  For that you need to get the compiler to not generate them in
> the first place.  I'm not aware of any compiler option to disable
> generating sethi instructions.
>
> It would be theoretically possible to remove sethi instructions in
> either linker as a relaxation, but it would require a decent amount of
> code analysis, or it would require compiler support.  None of this
> exists as far as I know.
>
> Ian
>