Build system needs writable /opt/nre-cross-x86_64/

[blitz]

% scons -c                             
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Cleaning targets ...
Removed /opt/nre-cross-x86_64/lib/gcc/x86_64-pc-nulnova/4.6.3/crt0.o
Removed /opt/nre-cross-x86_64/lib/gcc/x86_64-pc-nulnova/4.6.3/crt1.o
Removed /opt/nre-cross-x86_64/lib/gcc/x86_64-pc-nulnova/4.6.3/crtn.o
scons: done cleaning targets.

nre % scons /opt/nre-cross-x86_64
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
ASPP build/x86_64-release/libs/libstdc++/crt0.o
Install file: "build/x86_64-release/libs/libstdc++/crt0.o" as "/opt/nre-cross-x86_64/lib/gcc/x86_64-pc-nulnova/4.6.3/crt0.o"
AS build/x86_64-release/libs/libstdc++/crt1.o
Install file: "build/x86_64-release/libs/libstdc++/crt1.o" as "/opt/nre-cross-x86_64/lib/gcc/x86_64-pc-nulnova/4.6.3/crt1.o"
AS build/x86_64-release/libs/libstdc++/crtn.o
Install file: "build/x86_64-release/libs/libstdc++/crtn.o" as "/opt/nre-cross-x86_64/lib/gcc/x86_64-pc-nulnova/4.6.3/crtn.o"
scons: done building targets.

[blitz]

A solution seems to be to use -nostartfiles and keep crt?.o in the NRE build tree.

[Nils-TUD]

I don't really understand the problem. The folder is already writable, isn't it? Ok, one could argue that it isn't nice to change files in the cross-compiler-folder. The plan was to make the cross-compiler usable without having to pass special arguments. So basically, make it usable like your host compiler. Although I've just seen that there are currently other issues that prevent that :/ hm...what do you think...should we fix the things to make it usable like the host compiler or rather leave the cross-compiler-folder untouched and pass the required arguments in the scons scripts to make it work?

[blitz]

/opt should never be user-writable. I vote for passing locally built crtX.o as compiler parameters.

Julian

Nils Asmussen notifications@github.com wrote:

I don't really understand the problem. The folder is already writable, isn't it? Ok, one could argue that it isn't nice to change files in the cross-compiler-folder. The plan was to make the cross-compiler usable without having to pass special arguments. So basically, make it usable like your host compiler. Although I've just seen that there are currently other issues that prevent that :/ hm...what do you think...should we fix the things to make it usable like the host compiler or rather leave the cross-compiler-folder untouched and pass the required arguments in the scons scripts to make it work?

---

Reply to this email directly or view it on GitHub: https://github.com/TUD-OS/NRE/issues/24#issuecomment-10360555

Sent from Kaiten Mail. Please excuse my brevity.

[blitz]

We could add them to any of the libs, we just have to make sure to mark the start symbol as EXTERN in the linker script.

[hrniels]

That's more difficult than I thought :/ If I specify the startup files manually (in the same order, i.e. crt0.o crt1.o crtbegin.o $other_objects crtend.o crtn.o) and use -nostartfiles, exceptions stop working. The catch handlers aren't found anymore and thus abort() is called. By comparing the output of objdump --dwarf=frames I saw that the zero-length entry is in the middle of all entries (and at the end when using the working approach). That seems to be the reason for the problem. I've also seen by using -v when compiling to see all options to collect2, that with -nostartfiles the crtend.o and crtn.o are in front of the libraries and without -nostartfiles they are behind them. So, this is probably the reason for the wrong generation of the eh_frame stuff. Note that they are even before the libraries if I put them behind the libraries in my g++ call (by changing env['LINKCOM'] of scons). Thus, I don't have any idea how to change that. Probably you have to change that somewhere deep in gcc, which I definitely don't want to do. And the question is whether somebody ever tried to use -nostartfiles and still have exception-support. That's a bit weird anyway.

I guess, if nobody has an idea how to fix that, we have to live with the current situation :(

[blitz]

Maybe the Fiasco or Genode people have some insights to spare here.

[hrniels]

@nfeske Do you have any idea how to solve that?

[nfeske]

On Genode, we don't use the tool-chain's startup files but do all the C++ initialization in our cxx library (located at base/src/base/cxx). The option -nostartfiles is new to me. We just use -nostdlib -Wl,-nostdlib.

For example, linking core (for NOVA x86_32) looks as follows:

libs=/open/build/genode/nova_x86/var/libcache;
/usr/local/genode-gcc/bin/genode-x86-g++ -Wl,-melf_i386 -Wl,-gc-sections
-nostdlib -Wl,-nostdlib -Wl,-Ttext=0x100000 -march=i686 -m32
-Wl,-T -Wl,/home/no/src/genode/base-nova/src/platform/roottask.ld
-Wl,--whole-archive -Wl,--start-group
  cap_sel_alloc.o context_area.o core_mem_alloc.o core_printf.o
  core_rm_session.o cpu_session_component.o cpu_session_extension.o
  cpu_session_support.o dataspace_component.o dump_alloc.o echo.o
  io_mem_session_component.o io_mem_session_support.o
  io_port_session_component.o irq_session_component.o main.o main_thread.o
  pager.o pd_session_component.o pd_session_extension.o platform.o
  platform_pd.o platform_services.o platform_thread.o ram_session_component.o
  ram_session_support.o rm_session_component.o rm_session_support.o
  rom_session_component.o signal_session_component.o signal_source_component.o
  thread_start.o
  $libs/base-common/base-common.lib.a $libs/cxx/cxx.lib.a
  $libs/platform/platform.lib.a $libs/startup/startup.lib.a
  $libs/syscall/syscall.lib.a
-Wl,--end-group -Wl,--no-whole-archive
/usr/local/genode-gcc/bin/../lib/gcc/x86_64-elf/4.7.2/32/libgcc.a
-o core

That said, we have stripped down the GCC tool chain pretty much (making it independent from a libc, yet still supporting exceptions). So it may largely differ from the tool chain you are using. If you like to have a look, you can find the tool-chain script at tool/tool_chain).

[hrniels]

hm, ja, perhaps its better to completely ignore the gcc-startup-stuff and do it on our own. This will probably also "solve" the other problem with the wrong eh_frame info in crtend.o. Thanks, I'll try that and see how it works out.

[blitz]

:+1: