[lld] r249752 - Revert: r249728 - Roll back r249726 and r249723 because they broke buildbots.

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Tue Oct 13 08:51:18 PDT 2015


I have a mixed feeling about this. Setting familiar values is
probably psychologically better because you wouldn't even think about why
the values are the same as before. On the other hand side, this is
undeniably a cargo cult.

That being said, I'm inclined to Rafael's suggestion. We are serious about
the linker, and it's not only me who envision that LLD be one of the
standard tools in the Unix world. We would be able to simply stop that
cargo cult ourselves.

On Tue, Oct 13, 2015 at 8:26 AM, Rafael EspĂ­ndola <
llvm-commits at lists.llvm.org> wrote:

> > I had originally thought that they had been causing problems, but going
> back and restoring the original value (but keeping the page-size fix, which
> definitely is necessary), sill produces a working hello-world binary. Thus,
> I don't have a good answer for you, except to say that these are the same
> magic values that ld.gold uses. That having been said, I'd prefer to keep
> them this way. Poking around in the debugger, this makes the addresses look
> more like what I'm used to seeing, and FWIW, matching the behavior of
> existing linkers here seems like a prudent approach.
>
> So, this is a small example of "cargo coding" I would like to avoid.
>
> Changing the values only when we actually know why their are needed
> seems a much better solution. In the X86_64 case that is how we found
> out what the restrictions actually were and have them documented in a
> comment.
>
> I can see why it has to be 64k aligned on ppc, but the original values was
> too.
>
> Would you mind reverting the getVAStart part until we actually know of
> a reason why a given architecture has to be different?
>
> Thanks,
> Rafael
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151013/39220e01/attachment.html>


More information about the llvm-commits mailing list