[HN Gopher] A ToC of Ian Lance Taylor's 20-part Linkers essay (2...
___________________________________________________________________
A ToC of Ian Lance Taylor's 20-part Linkers essay (2008)
Author : noch
Score : 94 points
Date : 2021-06-09 09:32 UTC (13 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| Ericson2314 wrote:
| Well now gold is stagnating
| https://www.phoronix.com/scan.php?page=news_item&px=GNU-Gold....
| I think if google had waited a few years gold would have just
| _been_ lld, and this all would have been avoided.
| compiler-guy wrote:
| LLD is substantially faster than gold (largely because it does
| multithreading vastly better, but for other reasons as well,
| LLD discards some long-held linking semantics in the name of
| speed).
|
| It took a ground-up rewrite to make it so. Rui Ueyama was
| employed by Google while he wrote LLD for ELF--it was his
| primary assignment, bought and paid for by Google.
|
| So Google didn't just wait. It moved on to the next step.
| CalChris wrote:
| Semantics? I know that LLD discarded the all-format
| architecture of gnu ld; arguably it got that idea from gold
| which is ELF only. But what semantics did it discard?
|
| I'm a huge fan of LLD by the way. But in addition to
| performance and its implementation architecture, I think
| licensing had something to do with LLD's success.
| int3 wrote:
| https://lld.llvm.org/NewLLD.html#key-concepts
|
| > The semantics of LLD's archive handling are different
| from the traditional Unix's. You can observe it if you
| carefully craft archive files to exploit it. However, in
| reality, we don't know any program that cannot link with
| our algorithm so far, so it's not going to cause trouble.
| compiler-guy wrote:
| I run into issues with these updated semantics not
| exactly routinely, but with some regularity. They can
| always be fixed, but often it is an annoying hassle.
| CalChris wrote:
| Also by Ian Lance Taylor:
|
| _A New ELF Linker_
|
| https://storage.googleapis.com/pub-tools-public-publication-...
|
| _Gold_
|
| https://www.airs.com/ian/gold-slides.pdf
| rkangel wrote:
| Suggested better title: A ToC of [Ian Lance Taylor's] 20 part
| linker essay
| gumby wrote:
| I've only seen that notation (humans' names in square brackets)
| on Hackaday. Is it used elsewhere?
| rkangel wrote:
| The notation I'm using isn't as specific as 'human name in
| square brackets'. It's the more standard approach editorial
| approach used to add context when pulling out a quote.
|
| If you read the original text the context would be obvious
| but with the quote on its own it doesn't make sense so you
| want to add that context back in. That's done in square
| brackets to indicate that it is added and not part of the
| original quote.
| Ericson2314 wrote:
| If this is some parse-trees-for-nerd-readers things, it
| really should be [...]'s.
|
| I always do ". for quotes within the sentence too. The lisper
| in me won't let it be otherwise.
| jcranmer wrote:
| The syntax is used where you're quoting text, but you're
| replacing some text with other text for explanatory purposes.
| So, for example, if the original quote was:
|
| > The majority, however, uses this factor to create a
| distinction between declaring and implementing code that in
| effect removes copyright protection from declaring code.
|
| Standing alone, you might not realize what "this" refers to.
| Instead, you'd substitute an explanation:
|
| > The majority, however, uses [the nature of copyrighted
| work] factor to create a distinction between declaring and
| implementing code that in effect removes copyright protection
| from declaring code.
|
| In practice, one of the most common replacements is replacing
| a pronoun with a name. So "his" becomes "[John Doe's]".
___________________________________________________________________
(page generated 2021-06-09 23:02 UTC)