[lld] r244934 - Template OutputSection only over Is64Bit.

Sean Silva via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 10 11:20:06 PDT 2015


On Thu, Sep 10, 2015 at 6:27 AM, Rafael EspĂ­ndola <
rafael.espindola at gmail.com> wrote:

> On 9 September 2015 at 17:58, Rui Ueyama <ruiu at google.com> wrote:
> > Sorry to resurrect this old thread, but as I take a look again at the ELF
> > Writer's code, I found that this patch made the code a bit messy. Some
> > functions or classes are specialized only for `Is64Bits` and others are
> for
> > `ELFT`, although `ELFT` works for both cases. I really prefer code
> > simplicity over marginal efficiency at this stage of development, so I
> agree
> > with Sean. Can I roll it back?
>
> The main value I see with the current setup is that the members we
> have are plain structs. This means that they print cleanly on a
> debugger.
>
> The structs in ELFTypes.h are "unreadable". One has to fetch
> individual fields and cast them to the proper type to read the value,
> something like:
>
> p (uint32_t) Value->st_name.
>
> The logic of what is templated over ELFT or Is64Bits is actually
> pretty simple: Stuff that reads inputs is ELFT. Stuff that we
> construct is Is64Bit.
>

How can this handle constructing a big-endian output file from a
little-endian host? Or maybe I'm not understanding what you mean?

-- Sean Silva


>
> And last, it does reduce code duplication and increases the alignment
> of the stuff we construct.
>
> So my preference would be to keep it as is for now.
>
> Cheers,
> Rafael
>
> P.S.: Once we can link something big but simple (static clang with
> musl for example), I intend to benchmark and revisit the file output
> strategy, so I will be taking a thorough look at this fairly soon.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150910/a28a3945/attachment.html>


More information about the llvm-commits mailing list