On Fri, Jan 17, 2020 at 10:01 AM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote: > > On Fri, Jan 17, 2020 at 7:30 AM Nick Desaulniers > <ndesaulniers@xxxxxxxxxx> wrote: > > > > On Wed, Jan 15, 2020 at 3:53 AM Ilie Halip <ilie.halip@xxxxxxxxx> wrote: > > > > > > The semantics of `--undefined` differ between ld.bfd and ld.lld: > > > $ echo | gcc -x c -c - -o a.o > > > $ echo "EXTERN(test)" > a.lds > > > $ ld.bfd a.o -t a.lds -o - 2>/dev/null && objdump -t | grep test > > > 0000000000000000 *UND* 0000000000000000 test > > > $ ld.lld a.o -t a.lds -o - 2>/dev/null && objdump -t | grep test > > > $ > > > > > > When building with CONFIG_STM=m, there are no in-kernel users of memcat_p() > > > and ld.lld discards this symbol because it's linked in via --no-whole-archive. > > > It's marked as undefined by a linker script but ld.lld discards it anyway (as > > > seen in the above snippet). > > > > > > Work around the ld.lld behavior by moving the object file to obj-y. > > > > > > Signed-off-by: Ilie Halip <ilie.halip@xxxxxxxxx> > > > Link: https://github.com/ClangBuiltLinux/linux/issues/515 > > > > Thanks for the patch. This solves the observed linkage failure. > > Maybe Masahiro has more input based on the discussion in the above > > Link? > > Sorry, I did not notice that thread until now. > I will take a look at it when I have time. > > > This patch does not seem to be a proper fix. > > If this fix-up were acceptable, theoretically, > all objects that contain EXPORTED_SYMBOL > would need to be turned into obj-y from lib-y ? > > > Tested-by: Nick Desaulniers <ndesaulniers@xxxxxxxxxx> Hi Masahiro, lld ELF maintainer here. This seems to the only blocker of `LD=ld.lld allmodconfig` (https://github.com/ClangBuiltLinux/linux/issues/839). Hope you can help if you think there is a more complete fix. Below is some (probably obscure) explanation why I think the GNU ld -u behavior is not consistent and lld should not match: If a.o has an undefined symbol foo, `{ld.bfd,ld.lld} -shared a.o` will place foo in .dynsym . GNU ld's EXTERN(foo) and -u foo behavior is consistent with its documentation with regard to .symtab, but it is not consistent with regard to .dynsym. `ld.bfd -shared -u test a.o` does not place test in .dynsym. So an undefined symbol added by -u is different from a regular undefined symbol. The different behavior for .dynsym is understandable: if GNU ld places foo in .dynsym, the shared object will likely have an unresolved reference at run time and will thus be rejected by ld.so. So for .dynsym, GNU ld's behavior is actually similar to lld's: -u foo triggers linking of an archive (if the archive defines foo). Additionally, lld has an extension --undefined-glob=<pattern>, which is similar to multiple -u. The only reasonable behavior for a pattern argument is to trigger linking of archive definitions. This is consistent with lld's current interpretation of -u. Reviewed-by: Fangrui Song <maskray@xxxxxxxxxx>
