This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC PATCH]: Sparc gold support


David Miller <davem@davemloft.net> writes:

> Here is a request for comments posting of my gold support patch.  I
> know it needs some work.
>
> Firstly I know the gold/configure* aren't right.  What I want to be
> able to say is that if you ask for the sparc target, we need to enable
> support for both endiannesses and both 32-bit and 64-bit support.
> Any suggestions?
>
> Next, there is a .bss alignment hack in the copy reloc handling
> of the sparc target.  As indicated in the comment it is only there
> until the .bss alignment bug I reported two days ago gets
> worked out.
>
> Finally, I realize that the sparc target class is heavily
> templated and needs to be improved as it generates a lot of
> code currently.  Either I can do some specializations, some
> abstract base class scheme, or some combination of the two.
> In particular in this area, I am looking for suggestions.
>
> On sparc-unknown-linux-gnu all gold test cases pass.
>
> On sparc64-unknown-linux-gnu the non-pic shared test cases fail, but I
> know why and am investigating a way to handle it.  Although, as I
> mentioned the other day, the BFD linker gets these cases wrong so my
> gold sparc target is bug compatible :-)

I looked through the code, and it looks great.

Are there really little-endian SPARC targets?  A lot of the target
code is templated on big_endian, but there is no little-endian
selector or Target_info structure.

The dst_mask variants of the relocation function should perhaps be in
reloc.h.

I wouldn't worry about the size of the generated code.  There isn't a
lot of straight duplication there.  The functions all do some work
that is size specific.  Any given link is only going to use one size,
so there aren't any instruction cache issues here.  Anything you do to
reduce the amount of generated code is going to slow down the linker a
tiny little bit when you eventually switch on the size.  So reducing
the generated code would just save executable file size at the cost of
runtime.  The executable file is about 1.5M, and you couldn't save
much of that.  So overall I wouldn't worry about it.

Thanks!

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]