Missing cross reference table output (-Wl,--cref) option

[oshamash]

getting the following message when I try using it mold: fatal: unknown command line option: --cref
currently this got it due to me building with RTE (DPDK) which enforces this flag

From ld man:

--cref
    Output a cross reference table. If a linker map file is being generated, the cross reference table is
    printed to the map file. Otherwise, it is printed on the standard output.
    The format of the table is intentionally simple, so that it may be easily processed by a script if
    necessary. The symbols are printed out, sorted by name. For each symbol, a list of file names is given. 
    if the symbol is defined, the first file listed is the location of the definition. The remaining files contain
    references to the symbol.

Is there some similar flag/feature I can enable if I want to use mold ?

[rui314]

We have --print-map, --print-dependencies and --print-dependencies=full options whose roles overlap with --cref, so I want to avoid implementing --cref. Can you give me a repository's URL at which I can see how --cref flag is being used in a real project?

[oshamash]

@rui314 we are using an older version of DPDK, when you build an app for it - it will invoke this by default
(to be completely honest, I'm not sure if we care too much for it for production cases - for now I removed it and seem ok-ish)
see: https://github.com/DPDK/dpdk/blob/v20.08/mk/rte.app.mk#L403
I would of course prefer to use the code unmodified, but seeing as newer DPDK comes with meson.build and without this flag, you can probably ignore this feature request as they stopped using it in newer versions

EDIT: as a side-note, I do seem to encounter some problems with these applications now that I link with mold - but I'll run some tests and see if they relate/not to this flag (I really hope not) and/or changes to cache due to changing linker

[rui314]

I don't know why they added --cref in their Makefile, but it may be for "just in case". It looks like the file isn't used by other parts of the Makefile.

Feel free to file a new bug for the new issue. We are happy to investigate.

[oshamash]

I don't know why they added --cref in their Makefile, but it may be for "just in case". It looks like the file isn't used by other parts of the Makefile.

Feel free to file a new bug for the new issue. We are happy to investigate.

It's not used in their Makefile because this is meant for application you compile yourself with the RTE/DPDK "infra"
usage is as such:

# Default target, can be overridden by command line or environment
RTE_TARGET ?= x86_64-native-linuxapp-gcc

include $(RTE_SDK)/mk/rte.vars.mk

# binary name
APP = my_app

RTE_OUTPUT = ${SRCDIR}/build/${RTE_TARGET}/
# DPDK calls itself from the makefile..
# We need to add the parameters in the second call, the first one doesn't apply.
ifneq ($(NOT_FIRST_CALL),)

SRCS-y += $(shell find ${SRCDIR} \( -name "*.c" -o -name "*.cpp" \) -printf "%f ")
VPATH += $(shell find ${SRCDIR} -type d)
INC += ${SRCDIR}

# App flags
CPPFLAGS += -I${SRCDIR} -std=c++11
CPPFLAGS += -I${RTE_SDK}/${RTE_TARGET}/include
CFLAGS += -I${SRCDIR} -Werror -Wno-format-nonliteral
LDFLAGS += -ld -lstdc++

# Change linker to MOdernLDinker (silent D), see https://github.com/rui314/mold
# TODO(devops): once GCC supports -fuse-ld=mold don't hack it by using GOLD as alias
LDFLAGS += -fuse-ld=gold

ifeq ("${DEBUG_MODE}", "1")
$(info Compiling app in debug mode!)
CFLAGS += -DEBUG_MODE
CFLAGS += -fsanitize=address -fno-omit-frame-pointer -fsanitize=undefined
# Using "-Og -ggdb3" resulted optimized out variables, which arent' optimized out using "-O0 -g"
CFLAGS += -O0 -g
#CFLAGS += -Og -ggdb3

# Flags for code-coverage.
CFLAGS += --coverage
LDFLAGS += -lgcov
else
$(info Compiling app in release mode!)
CFLAGS += -O3 -g
endif
$(info ========================================================)
endif

CFLAGS += -fPIC
CPPFLAGS += -fPIC

include $(RTE_SDK)/mk/rte.extapp.mk

[oshamash]

Small update: after doing extensive tests, it seems that there is 0 difference in runtime.
I'm closing ticket since it is (so-far) a useless feature 🙂

[Arusekk]

The --cref flag is also used by micropython as a measure enhancing manual optimization (to check what symbols are used by what object files). The difference is that the map files are augmented with a fairly simple trailer similar to the following, when using either bfd or lld (have not checked gold, but I assume it is very similar to bfd; both start values on column 50, but lld skips info about symbol versions and xrefs to versions):

Cross Reference Table 

Symbol                                            File  
some_symbol                                       file_defining_some_symbol.o
                                                  file_using_some_symbol.o
another_symbol                                    xref1.o
                                                  xref2.o
                                                  xref3.o

Note that it also rolls its own linker for its embedded code, so the extra information might be beneficial for the developers to debug said linker. (Of course the reason I wrote this comment is that micropython fails to build with LDFLAGS_EXTRA=-fuse-ld=mold unless the problematic flag is removed from its makefiles.)

[rui314]

@Arusekk For that purpose, we have --print-dependencies. Have you tried that?

[Arusekk]

Sure, it contains similar data, but the differences are --print-dependencies always prints its output to stdout (--cref appends to the map file), and dependencies are sorted/grouped by object (section) rather than by symbol. It also only prints undefined/common symbols (usage), whereas --cref prints definitions as well as usage, in an arguably simpler format.

And finally, for some reason while linking micropython (mpy-cross executable) without --cref works, replacing --cref with --print-dependencies results in some out-of-bounds symbol table access on mold 2.32.1 with gcc (Gentoo Hardened 14.1.1_p20240720 p4):

/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/span:286: constexpr std::span<_Type, _Extent>::element_type& std::span<_Type, _Extent>::operator[](size_type) const [with _Type = mold::elf::ElfSym<mold::elf::X86_64>; long unsigned int _Extent = 18446744073709551615; reference = mold::elf::ElfSym<mold::elf::X86_64>&; size_type = long unsigned int]: Assertion '__idx < size()' failed.
collect2: fatal error: ld terminated with signal 6 [Przerwane]
compilation terminated.

Anyway.
How about ignoring --cref for compatibility (or with a warning maybe)? The map file format is already different than any other linker out there, so I guess it would not do much harm?

[rui314]

Let me fix the crash issue.

The --print-dependencies output contains information about definitions as well as usage. In each file, the first file depends on (via an undefined or a common symbol) the second file which provides a definition. And I think it's much easier to parse as it is line-oriented. --cref output is hard to parse IMO.

I don't think ignoring --cref is a good idea, because when a user passes that option, he/she would naturally expect that the file is created. Making --cref a synonym for --print-dependencies may be better, but I'm not sure if that's still a good idea.