lld reports undefined symbols, ld.bfd links w/o errors

[stsp]

lld.tar.gz

Attached is a test-case.
It has many objects and 2 scripts:
test_bfd.sh and test_lld.sh.
They are identical except for calling
different linkers.

test_bfd.sh doesn't print any errors
or warnings. It links kernel.elf
which actually works.
test_lld.sh throws many unclear errors.

[MaskRay]

Please can you make the description clearer? You can paste the command the the exact output to save others' time.

% zsh test_lld.sh
ld.lld: error: kernel.ld:11: at least one side of the expression must be absolute
ld.lld: error: kernel.ld:12: at least one side of the expression must be absolute
ld.lld: error: kernel.ld:13: at least one side of the expression must be absolute
ld.lld: error: kernel.ld:20: at least one side of the expression must be absolute
ld.lld: error: undefined symbol: >>:s8:_DGROUP~:#00000004
>>> referenced by /home/stas/src/fdpp/kernel/io.asm
>>>               io.o:(_IO_TEXT+0x88)
>>> referenced by /home/stas/src/fdpp/kernel/io.asm
>>>               io.o:(_IO_TEXT+0xB3)
>>> referenced by /home/stas/src/fdpp/kernel/io.asm
>>>               io.o:(_IO_TEXT+0xF5)
>>> referenced 44 more times
...

The dot value is represented as an output section plus an offset. It's unclear when two addresses are added, so lld reports at least one side of the expression must be absolute.
While this is more rigid, it helps sort out issues when writing linker scripts, which is a good thing.

By changing these _LGROUP~ = . + _LOADADDR; to _LGROUP~ = ABSOLUTE(.) + _LOADADDR;, we can fix this type of errors.

Then we will have undefined symbol: >>:s8:_DGROUP~:#00000004.

kernel.o utilizes symbol type 8 symbols that LLVM doesn't understand.

% /tmp/Rel/bin/llvm-readelf -s kernel.o
...
   308: 00000000     0 <unknown>: 8 GLOBAL DEFAULT UND >>:s8:_IGROUP~:#00000004
   309: 00000000     0 <unknown>: 8 GLOBAL DEFAULT UND >>:s8:_LGROUP~:#00000004
   310: 00000000     0 <unknown>: 8 GLOBAL DEFAULT UND >>:s8:_LGROUP~:#00000004
   311: 00000000     0 <unknown>: 8 GLOBAL DEFAULT UND >>:s8:_LGROUP~:#00000004
...

It seems that symbol type 8 (STT_RELC) was used by an old arch in BFD: Toshiba mep. No other gas port emits such relocations. https://gcc.gnu.org/pipermail/gcc/2012-August.txt#:~:text=STT_RELC
It looks like that this is a legacy feature in one single gas port that LLVM doesn't support. I don't think we will support this extension.

[stsp]

Sorry, I didn't know the test-case
is not enough. Had to post the output
for sure. Especially since it doesn't
match yours:

$ ./test_lld.sh
ld.lld: error: undefined symbol: >>:s8:_IGROUP~:#00000004
>>> referenced by /home/stas/src/fdpp/kernel/kernel.asm
>>>               kernel.o:(PSP+0x19)

ld.lld: error: undefined symbol: >>:s8:_LGROUP~:#00000004
>>> referenced by /home/stas/src/fdpp/kernel/kernel.asm
>>>               kernel.o:(_FIXED_DATA+0x34)
>>> referenced by /home/stas/src/fdpp/kernel/kernel.asm
>>>               kernel.o:(_FIXED_DATA+0x4A)
>>> referenced by /home/stas/src/fdpp/kernel/kernel.asm
>>>               kernel.o:(CONST+0x3)
>>> referenced 13 more times

ld.lld: error: undefined symbol: >>:s8:_DGROUP~:#00000004
>>> referenced by /home/stas/src/fdpp/kernel/kernel.asm
>>>               kernel.o:(CONST+0x15F)
>>> referenced by /home/stas/src/fdpp/kernel/kernel.asm
>>>               kernel.o:(CONST+0x163)
>>> referenced by /home/stas/src/fdpp/kernel/kernel.asm
>>>               kernel.o:(CONST+0x167)
>>> referenced 44 more times

ld.lld: error: undefined symbol: >>:s8:_PGROUP~:#00000004
>>> referenced by /home/stas/src/fdpp/kernel/kernel.asm
>>>               kernel.o:(HMA_TEXT+0x2)

So I don't have the errors about
at least one side of the expression must be absolute.
Why do they appear for you?

By changing these _LGROUP~ = . + _LOADADDR; to _LGROUP~ = ABSOLUTE(.) + _LOADADDR;, we can fix this type of errors.

I think this will make them into SHN_ABS.
Dynamic linker has this check:

        /* not relocating against abs symbol */
        if (sym.st_shndx == SHN_ABS)
            continue;
        val = (uint16_t *)(state->addr + state->load_offs + rel.r_offset);
        *val += seg;

They were likely made relative on purpose.
And I actually don't see that error at all.
Why does it appear for you and not for me?
LLD 19.1.5 (compatible with GNU linkers)

[stsp]

I checked your fix, and indeed it
produces the crashing kernel. But
I agree there is a bug: _LOADADDR
must be absolute. So this seems to
work:

-    _LOADADDR = DEFINED(loadaddr) ? loadaddr : .;
+    _LOADADDR = DEFINED(loadaddr) ? loadaddr : 0;

But since I am not getting these
errors at all... could you please tell
me if they go away with this change? :)

[MaskRay]

Many people would leave when they see the unclear subject.
People make undefined symbols linker errors every day.
"reports undefined symbols" conveys very little information and many potential helpers would just leave.
You should be specific about the issue you have seen.

http://www.catb.org/~esr/faqs/smart-questions.html
Use meaningful, specific subject headers
Be precise and informative about your problem

Dynamic linker has this check:

This is not clear. Almost all readers aware of dynamic linkers will think about rtld in glibc, musl, FreeBSD, SerenityOS, etc.

It seems that your comment is about your project dosemu2/fdpp, where you adopted
the STT_RELC extension in binutils
dosemu2/fdpp#172 (comment)

So, STT_RELC appears to be for the Toshiba mep BFD port with gas and ld support.
https://sourceware.org/pipermail/binutils/2007-January/050299.html

While the assembler support is only enabled for Toshiba mep, the linker support is enabled for all ports.
However, I don't think this was intended, or at least, won't be supported by a wide range of ELF tools.

https://inbox.sourceware.org/gcc/CAKOQZ8xJUh8KXt3hG48mVUCQmdcm7TijOiY_zgOFY6p35QNN2g@mail.gmail.com/ (2012)

ELF is designed to permit fast program loading at runtime, and to permit fast linking. Changing symbol and relocation values to take general expressions works against that goal.

If I build GNU ld with STT_RELC support removed (binutils-gdb/bfd/elflink.c:11777), I'll get the similar undefined reference linker error.

/home/stas/src/fdpp/kernel/kernel.asm:(PSP+0x19): undefined reference to `>>:s8:_IGROUP~:#00000004'

lld will not support this STT_RELC extension.
If you still want complex relocations, since you use --emit-relocs and your loader interprets relocations, you can use defined symbols and make the linker forward the relocation to the output.

[stsp]

Ok, thanks for info.
Got the point about bad subject.

But I am very confused about your
other error, ld.lld: error: kernel.ld:11: at least one side of the expression must be absolute
Not only because I don't even get it.
But also because this works:
[1]

_LGROUP~ = ABSOLUTE(.) + .;

while this crashes:
[2]

_LOADADDR = .;
_LGROUP~ = ABSOLUTE(.) + _LOADADDR;

While this works:
[3]

_LGROUP~ = . + .;

on bfd and still doesn't produce the
needed error on my lld...
This crashes (expected):
[4]

_LGROUP~ = ABSOLUTE(.) + ABSOLUTE(.);

So it appears:

• just passing . via the intermediate
  variable is enough to make it absolute
  on ld.bfd? It makes [2] similar to [4].
• my version of lld allows both operands
  to be relative, while yours complains?
• bdf also allows both to be relative? [3]
• something was recently changed in
  your ver of lld, which disallows both
  relative, whereas its allowed on bfd,
  so incompatible change?

Very strange!

[stsp]

If you still want complex relocations, since you use --emit-relocs and your loader interprets relocations,
you can use defined symbols and make the linker forward the relocation to the output.

Its not as simple as that.
My loader does not interpret the
relocations - ld does. My loader
only looks them up to add the
load address. Load address is the
same value for all relocs. So I really
can't work if ld didn't interpret the
relocations for me.

[stsp]

I filled these tickets to binutils:
https://sourceware.org/bugzilla/show_bug.cgi?id=32464
https://sourceware.org/bugzilla/show_bug.cgi?id=32463
After your explanation I believe
the behaviour should be unified.
The only unexplained thing remains
why I don't get the needed error
from lld with the original test-case,
whereas you have it.
But I was able to replicate it with
the new test-case.

[stsp]

ELF is designed to permit fast program loading at runtime, and to permit fast linking.
Changing symbol and relocation values to take general expressions works against that goal.

Just for the nit-pick, you messed up
this part a bit. Ian replied to some
proposal of adding a high-level languages
to ELF. This was another proposal. And
just 1 msg later he was pointed to RELC
proposal, so the correct link is:
https://inbox.sourceware.org/gcc/CAKOQZ8wWzn1te8BkeF16ZXmYpnoraH-gY68k6WNR0BwMML9cmQ@mail.gmail.com/
As you can see, this time he provided
an entirely different reply.