Error: LD: symbol not found: '__data_start'

[Alexander Tormasov]

Hello Norman,
thanks for answer

> On 14.06.21 17:27, Alexander Tormasov via users wrote:
>> so, seems that the best solution (safe, no changes in algorithms/data
>> size/etc) seems to be to add these symbols to ldscript as proposed by
>> previous patch.
> this conclusion is leading us nowhere.
> 
> Please consider adding whatever symbols you like to a linker script of
> your's and point the build system's LD_SCRIPT_DYN variable to your
> linker script. The hook is in place to accommodate situations like this.
> So please use it instead imposing changes on the default linker script.

Sorry, I am not that familiar with ld scripts.
I have a problem with LD_SCRIPT_DYN - I did not found how to use it.
in short, if I set it inside my target.mk file to bulid application, like this:
TARGET = test-go
SRC_GO = main.go

LIBS = base libc libm libatomic libbacktrace libffi libgo libgo_support stdcxx

LD_SCRIPT_DYN = $(PRG_DIR)/my_genode_dyn.ld

CC_CXX_WARN_STRICT =

then it completely ignored, because prg.mk which do include target.mk in the very beginning, 
and later include global.mk which contain the following (which override it):
#
# Linker script for dynamically linked programs
#
LD_SCRIPT_DYN = $(BASE_DIR)/src/ld/genode_dyn.ld


while prg.mk contains the following lines later:
#
# Add a list of symbols that shall always be added to the dynsym section
#
LD_OPT += --dynamic-list=$(BASE_DIR)/src/ld/genode_dyn.dl

LD_SCRIPTS := $(LD_SCRIPT_DYN)
LD_CMD     += -Wl,--dynamic-linker=$(DYNAMIC_LINKER).lib.so \
              -Wl,--eh-frame-hdr -Wl,-rpath-link=.

So, here, as you see, genode build system not only override it (I do not find any intermediate places to set it), but also unconditionally always add standard genode linker script via LD_OPT.

Finally it generate the following link command:
genode-x86-g++ -Wl,-melf_x86_64 -Wl,-gc-sections -Wl,-z -Wl,max-page-size=0x1000 -Wl,--dynamic-list=/var/services/homes/admin/gen/21.05/repos/base/src/ld/genode_dyn.dl -nostdlib -Wl,-nostdlib -Wl,-Ttext=0x01000000 -m64 -mcmodel=large -Wl,--dynamic-linker=ld.lib.so -Wl,--eh-frame-hdr -Wl,-rpath-link=. -Wl,-T -Wl,/var/services/homes/admin/gen/21.05/repos/base/src/ld/genode_dyn.ld -Wl,--whole-archive -Wl,--start-group main.o $libs/base/base.lib.a $libs/libatomic/libatomic.lib.a $libs/libbacktrace/libbacktrace.lib.a $libs/libffi/libffi.lib.a $libs/libgo/libgo.lib.a $libs/libgo_support/libgo_support.lib.a ld.lib.so libc.lib.so libm.lib.so stdcxx.lib.so vfs.lib.so  -Wl,--no-whole-archive -Wl,--end-group /var/services/homes/admin/gen/21.05/build/x86_64/var/libcache/base-linux-common/base-linux-common.lib.a /var/services/homes/admin/gen/21.05/build/x86_64/var/libcache/startup-linux/startup-linux.lib.a /var/services/homes/admin/gen/21.05/build/x86_64/var/libcache/cxx/cxx.lib.a /var/services/homes/admin/gen/21.05/build/x86_64/var/libcache/libc-stdlib/libc-stdlib.lib.a /var/services/homes/admin/gen/21.05/build/x86_64/var/libcache/libc-gen/libc-gen.lib.a /var/services/homes/admin/gen/21.05/build/x86_64/lib/libgo/libgobegin.a /var/services/homes/admin/gen/21.05/build/x86_64/lib/libgo/libgolibbegin.a /var/services/homes/admin/gen/21.05/build/x86_64/lib/libgo/.libs/libgo.a /usr/local/genode/tool/21.05/bin/../lib/gcc/x86_64-pc-elf/10.3.0/64/libgcc.a /usr/local/genode/tool/21.05/bin/../lib/gcc/x86_64-pc-elf/10.3.0/64/libgcc_eh.a -o test-go

And, I am not completely agree with your argument about modification of standard ld script.
I understand your general approach of minimisation of changes and related support.
Anyway, in short,
- this modification is a part of standard gcc code/binutils, not related to golang (it just use it)
- it does not take any resources like memory (just compilation alias)
- it does not require any support afterward
- it does not violate any security/etc approaches of genode and lower level OSes
- if I move complete ld script for golang to world (may be I can just define only necessary name in add-on script?), then it will be necessary to support it (if main genode ld script will somehow evolve…).

Sincerely,
	Alexander