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

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

On Wed, Mar 13, 2013 at 7:19 PM, Toby Thain 
<toby%telegraphics.com.au@localhost> wrote:
> On 13/03/13 3:09 PM, John Klos wrote:
>>
>> Hi,
>>
>> Should we invite Jake Hamby to be a NetBSD developer?
>>
>> John
>>
>
> As a VAX owner, I like the cut of his jib.
>
> --Toby


Thanks for the vote of confidence, Toby and John! I would love to join
the team if you'll have me. I have quite a list of things I'd like to
contribute to NetBSD, but I didn't want to engage the group until I
was confident that I'd have time to follow through.

I've been an engineer on the Android team at Google for the past three
years, so I know a thing or two about contributing code to large open
source projects. Google encourages employees to contribute to open
source projects, so there's only a small amount of overhead on my end
to get changes approved for release. Please keep in mind that my
NetBSD hacking is strictly a weekends and evenings project and not any
kind of "20% project" or anything Google-sponsored.

Quick status update on my progress with binutils / GCC 4.5 toolchain
support. I finished reading the ELF specs and have a good idea of
what's going on in elf32-vax.c so I should have a cleaned-up patch
ready in a few days to fix the off-by-one GOT table size bug. The
other necessary code change (so far) to GCC 4.5 for VAX is porting
forward the NetBSD codegen patch for "ffs" from GCC 4.1.2. I'll take
care of submitting the patches upstream, since I can always talk to
someone on the GCC team at Google if I run into any problems.

I discovered why /usr/bin/gdb compiled with GCC 4.1 was linking
against __clz_tab (a static table in libgcc.a that was marked "hidden"
for GCC 4.5) and therefore fails to start with a COPY relocation error
when I tried to run it inside a GCC 4.5 chroot. It's picking up the
reference to __clz_tab from /usr/lib/libkvm.so, which for some bizarre
reason is exporting that symbol in the GCC 4.1 version of libkvm.so.
So for backwards binary compatibility, it looks like we'll have to add
a hack to export __clz_tab in the GCC 4.5 version of libkvm.so (in
such a way that newly linked apps won't try to reference it), unless
it's okay to break binary compatibility because libkvm is a system
library and relatively few apps link against it. To avoid breaking
pkgsrc system utilities like "lsof", it seems like exporting the
symbol is the safest option.

The final piece of the puzzle, which I expected would involve some
work, is fixing a handful of test case failures in GMP and MPFR
related to limitations of VAX floating-point: no support for denorms,
(NaN == NaN) instead of (NaN != NaN), limited exponent range for
doubles, etc. I've run the test cases as well as the "tuneup" programs
(the MPFR tuneup has been running for about 2 days and should be
almost finished when I get home tonight) to generate the tuning
parameters.

So here's a question. The versions of GMP and MPFR currently in the
NetBSD tree are somewhat old (5.0.2 vs. 5.1.1 for GMP, 3.0.1 vs. 3.1.2
for MPFR). The current versions have more optimizations, and
particularly more CPU-specific optimizations (including tunings for
specific flavors of the various x86 chips). The latest versions of GMP
even include a few recent VAX-specific bug fixes! Is anyone planning
to upgrade those libraries in the tree? Are there any reasons why we
should stay with the older versions of the libraries? I'm guessing
that because the libs are only used for linking GCC/binutils and
aren't exported for other apps to use, that there just wasn't any
demand to upgrade the libraries, but if I need to grab upstream VAX
fixes that have already been written, it seems sensible to just go
ahead and upgrade the packages for all the platforms.

I'm sure the versions of GMP and MPFR in -stable are frozen at the
moment, especially so close to a release, so if there's demand to
backport the VAX fixes to the older versions of the libraries, I
should be able to do that, but if the consensus is that it'd be better
to upgrade to the current versions of GMP and MPFR, and if no-one else
wants to volunteer to do the work, I can definitely work on the
patches to upgrade those libraries in -current.

On a related note, it'd be nice to add some support for G-float
format, to support apps which require the extended exponent range
compared to the default D-float doubles. There's a GCC compiler flag
to generate G-float opcodes but the problem is that I believe you need
separate G-float versions of any library functions that take FP args
or return an FP result, so either some sort of multilib approach or
symbol versioning would be necessary. I'm not even going to try to
deal with G-float right now, but wanted to mention it. Presumably you
could compile the entire world using G-float, but then you'd break
binary compatibility with the majority of apps and I don't know how
much slower G-float math is compared to D-float, or if it's even
supported in hardware on my NVAX.

More to come in a few days. Stay tuned... :)

-Jake