[lld] Representation of lld::Reference with a fake target

A bit off topic: ARM Group relocations define a logical set of consequent instructions to be relocated to form one single address. For such relocations a 1 to 1 relation is also met, so no need of special processing in applyRelocation.

Concerning native format: it also introduced unneeded code complexity to me when I wanted to set calculated relocation addend back into the Reference object in the relocation handler to simplify further processing.
Since it crashed in tests because of native format conversion, I needed to keep calculated addend to pass it along the handlers instead of just calling ref.addend().

  • Denis.

I want to bring this again because I think it’s important.

It doesn’t make sense to store and load intermediate atoms/references in the middle of link, is it? Teaching LLD about how to read from YAML or Native object file is fine, and we probably want to teach LLD about how to emit a re-linkable object file in YAML or Native file. But the round-trip tests do more than that, right? The tests require more – dumping linker internal state to a file and reading it correctly.

Hi,

The round trip passes just tries to load a *complete* object file in YAML/Native format back.

The internal state should be the complete object file in native/yaml format.

If some state is not recorded and that is really needed in the writer, we should add that to the Atom model.

Shankar Easwaran

Hi,

The round trip passes just tries to load a *complete* object file in
YAML/Native format back.

The internal state should be the complete object file in native/yaml
format.

If some state is not recorded and that is really needed in the writer, we
should add that to the Atom model.

Again, not only saying we should do something, but please elaborate why you
think we should. Otherwise we can't discuss...

Shankar Easwaran

The RoundTrip passes was a method to verify the Atom model. When the pass
was written / reviewed, this pass was a way to verify that all information
passed to the writer was passed through an Atom.

I am completely ok to remove the pass as long as there is an alternative
with which we can verify.

Shankar Easwaran

The atom model is, compared to the traditional linker model, representing both symbol and its data as an “atom” and model relocations and other information as edges between atoms.

I think the atom model doesn’t mean nor require all atoms in memory are of the same type (or class) regardless of architecture/OS. They can be different subtype as long as output is correct. And that’s what we are doing with LLD. We have many subtypes of atoms or references. A reader for an architecture creates atoms of some type, and the corresponding writer for the architecture uses them. Architecture-independent passes work fine with derived classes of atom/reference because subtypes have compatible interface with super classes. It seems to be working, except the round-trip test.

The round-trip test is different from other passes in the sense that it needs to understand everything about given data (please compare this property with other passes). It needs to be able to write everything about a given (internal representation of) file and read them back. Otherwise we will lose data during round-trip. That’s what’s happening, right?

The point is again we don’t really need to save intermediate data. Only the round-trip passes need to do that. The round-trip tests test the features for themselves – not for others. This is just a burden, no?