--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot 
Uni-Bielefeld.DE> ---
> --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
> Uni-Bielefeld.DE> ---
>>> --- Comment #1 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
>>> Is there another way to get a section in earlier versions of Solaris?
>> What I initially did in LLVM's compiler-rt (which prompted the addition
>> of __start_SEC/__stop_SEC support to ld) was to add two startup files to
>> define the necessary labels and link the __start_SEC one early, the
>> __stop_SEC one late:
>> See sancov_begin.S and sancov_end.S.

The attached patch implements this.  There were a couple of unexpected
problems, though.

> To elaborate, here's my current plan:
> * Have some drtstuff.c like this
> #ifdef DRT_BEGIN
> void *__start_minfo[]
> __attribute__((used, section("minfo"), aligned(sizeof(void *)))) = { };
> #endif
> #ifdef DRT_END
> void *__stop_minfo[]
> __attribute__((used, section("minfo"), aligned(sizeof(void *)))) = { };
> #endif
>   and compile it into separate drtbegin.o/drtend.o.

This worked fine.  I'm wrapping it in __ELF__ to make certain there's
no attempt to compile it on targets without named section support.

> * Based on the outcome of DCFG_MINFO_BRACKETING, add them to
>   libgphobos.spec like this:
> %rename startfile startfile_orig
> *startfile: %(startfile_orig) drtbegin.o%s
> %rename endfile endfile_orig
> *endfile: %(endfile_orig) drtend.o%s

This works, too.  However, the substitution needs to be done using
AC_SUBST_FILE with the fragment above in a separate file.  Initially, I
put it into a make variable, but the multiline variable confused the
hell out of make.

> * This will have to be done explicitly for and
> since both are linked with -nophoboslib.

This is the part that didn't work the way I initially thought: I tried
to explicitly add drtbegin.o to *_la_LDFLAGS (so it comes at the very
beginning of the link line) and drtend.o to *_la_LDADD (so it comes at
the end).  I couldn't get this to work, though: libtool insisted on
always moving those two files (either as .o or .lo files) to the very
end of the link line, completely breaking the intended bracketing.
Preceding the object files with -Wl or -Wc didn't change a thing.

So instead I went for a different approach: have gdc in concert with
libgphobos.spec do the work even when linking and  The problem was that I still needed the
drtbegin.o/drtend.o files to be added despite the use of -nophoboslib.
To achieve that, I added a new -dstartfiles option.  I initially tried
-startfiles matching the existing -nostartfiles, but couldn't get that
option to be recognized by gdc.  Of course I now need to add the
matching -B options so both libgphobos.spec and drtbegin.o/drtend.o are

> Doing the equivalent of this manually allowed the libs to be linked on
> Solaris 10.  However, this was before the section_elf_shared.d work, so
> the resulting libs had unresolved references.

I first tried this on Solaris 11.3 because S10 has quite a number of
additional problems.  I needed only a single additional patch (to be
submitted separately) because unlike S11.4 the networking functions have
not yet been folded into libc, but live in separate libsocket and

With this patch, I could bootstrap sparc-sun-solaris2.11 and with as and
i386-pc-solaris2.11, each on S11.4 (where ld does section bracketing)
and S11.3 (where it doesn't).

A couple of additional comments/questions:

* I'm uncertain if we want -dstartfiles to be documented at all: it's
  purely internal, I believe.

* I've switched the's from -Xcompiler to -Wc because the
  latter is way less verbose and allows to apppend several
  comma-separated args.

* The Minfo_Bracketing assert in sections_elf_shared.d fails now, of
  course, but the file is usable even without linker-provided
  bracketing.  Should this go completely?

There still are a very large number of execution failures in the
libphobos and gdc.* testsuites, but this is already the case on S11.4
when the linker adds the minfo bracketing.  At least we get the runtime
libs to link now.

Reply via email to