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