Re: ld assertion failures building NetBSD-VAX with GCC 4.5

[Jake Hamby <jake.hamby%gmail.com@localhost>]

On Wed, Mar 13, 2013 at 12:45 AM, Martin Husemann 
<martin%duskware.de@localhost> wrote:
> On Tue, Mar 12, 2013 at 05:56:28PM -0700, Jake Hamby wrote:
>>        /* Allocate space in the .got and .rela.got sections.  */
>>        if (ELF_ST_VISIBILITY (h->other) == STV_DEFAULT
>> -  && (info->shared
>> -      || WILL_CALL_FINISH_DYNAMIC_SYMBOL (dyn, 0, h)))
>> +  || !WILL_CALL_FINISH_DYNAMIC_SYMBOL (dyn, 0, h))
>
> Excellent catch, can you please bring this up upstream as well, after it
> has settled?
>
> One (maybe stupid, I lack all context) question: why is the
> info->shared test not needed any more?

It's not a stupid question since it's not an obvious simplification.
The WILL_CALL_FINISH_DYNAMIC_SYMBOL macro will return either true or
false. If true, then the info->shared test is redundant, and if false,
the second branch will succeed.

I'm not entirely happy with the patch because I don't think these
generic ELF macros are being used consistently throughout elf32-vax.c,
and the general layout seems like it ought to be more similar to other
CPU-dependent files, e.g. for m68k. It does get me past the linker
failure I was seeing, and after I've had a chance to finish reading
Ulrich Drepper's "How To Write Shared Libraries", I'll have a better
idea of what's going on and what other small cleanups can be made.
Then I'll be able to defend the reasoning for exactly how these if
branches should look to make sure they cover all the ELF relocation
variants correctly.

Today I'm building gmp, mpfr, and mpc on VAX with GCC 4.1.x to see if
I can get all the test cases to pass. If any diffs are needed, then
I'll copy them to my crossbuild environment. I also want to run the
benchmark scripts for gmp and mpfr to generate better VAX tuning files
to minimize the overhead of using these libraries for math during
native compiles.

I've already found two areas for improvement, one VAX-specific and the
other NetBSD-specific. The VAX-specific feature that still needs to be
implemented is TLS support. It seems like it should be straightforward
to pick an arbitrary VAX register to use as a thread-pointer, since
the subroutine entry mask will preserve it across function calls. One
problem I can think of would be the case where TLS-aware code calls a
function that isn't TLS-aware, which in turn calls a function that is
TLS-aware. On m68k, a system call is needed to get the thread-pointer.
I wrote a hack last year to stash the value in the lower 32 bits of an
unused FP register with a special NaN signature to detect if the
register was used by anyone else. That hack wasn't accepted because
not all NetBSD-supporting m68k boxes include an FPU. So any tips on
how to implement TLS on VAX would definitely be appreciated.

The other non-VAX-specific optimization I'd like to implement is
.gnu.hash support for faster dynamic relocations at startup. FreeBSD
added support for .gnu.hash last year for all supported archs, based
on the DragonFly BSD implementation. Since I have access to alpha,
amd64, i386, ia64, m68k, macppc, and VAX systems at my house, I should
be able to merge that support into NetBSD and test it on all of those
platforms.

Regards,
Jake