Subject: as buggy?
To: None <port-vax@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: port-vax
Date: 11/10/2000 13:09:26
I'm having some coredump problems.  To cut to the chase, I believe they
are due to as producing incorrect relocation info when assembling
__sigsetjmp14.so.  All the r_extern bits seem to be clear, in marked
contrast to other .so files in libc.  However, it's not just as; I
tried patching the r_extern bits to 1 and dropping the resulting .so
file into libc, and the problem (siglongjmp() returns to its caller) is
still present.  (It's present only when dynamically linked; there could
also be something wrong in the dynamic linker, though the r_extern
thing made me suspect as -k.)

Comparing -current according to sup versus my source tree, I see only
changes that I can't believe make any difference:

- In gnu/usr.bin/gas.new
  - Makefile: changes controlling whether to build at all or not, and
     whether to do texinfo stuff
  - arch/sh3/targ-env.h: didn't investigate, as I'm on vax, not sh3
- In gnu/dist/gas
  - doc/as.texinfo: didn't investigate, as it's a doc file

I've rebuilt libbfd and as without optimization (all -O options removed
from bsd.sys.mk and sys.mk) and it made no difference.

objdump -r reports

BFD: bfd assertion fail /usr/src/gnu/lib/libbfd/../../dist/bfd/aoutx.h:2310

once per relocation entry, for both good .so files and the bad
__sigsetjmp14.so; for the bad file, the "VALUE" output column is wrong.
It doesn't do this for the .o versions, and the remarks about r_extern
above are based not on objdump output but rather on a small-and-stupid
program I wrote to read the relocation_info_vax structs out of the file
and dump their fields without any attempt to interpret them.  (Wetware
parsing of hexdump -C output agrees.)  I mention the objdump complaints
because they may indicate that libbfd is somehow not dealing correctly
with "as -k" style relocations.

Is this known?  Is there any known workaround?  For that matter, am I
alone in seeing it?  ("objdump -r /usr/src/lib/libc/__sigsetjmp14.o"
should be a reasonable test - does the VALUE column contain *jmp14
names or does it contain stuff like *ABS*?)

In case it matters, this is on a MicroVAX-II (running diskless - I have
only ra interfaces for it, and no significant amount of ra disk; the
NFS server is NetBSD/sparc running on a SS1).  I'm on 1.4T; I can
provide exact $NetBSD$ lines for any files of interest.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B