Re: Proposed changes for pdp11 --*magic options

[Stephen Casner <casner@acm.org>]

Nick,

You detected that my patch for PR 25677 exposed an additional
testsuite failure beyond those that were seen previously.  Is the set
of expected failures recorded somewhere, or is that just a comparison
that you make locally with before-and-after builds?  Shouldn't those
tests be marked with xfail: pdp11-*-* instead?  Or perhaps you've left
them as unexpected errors as a TODO to resolve why they occur?

After finding a fix for the new failure, I've been examining the
others.  Some could be easily fixed:

Running ../../ld/testsuite/ld-misc/defsym.exp ...
ERROR: /Users/casner/epos/binutils/binutils-gdb/ld/testsuite/ld-misc/start.s: assembly failed
UNRESOLVED: Build start.o

The assembler error is "Can not represent BFD_RELOC_32 relocation in
this object file format".  That occurs on the source line:

	.long foo

where foo is an address label that needs to be relocated.  This error
can be easily avoided and allow the test to pass by replacing .long
with .word or .dc.a so the relocation fits the 16-bit address for
pdp11.  Would that cause a problem for any other targets?


FAIL: ld-scripts/default-script1
FAIL: ld-scripts/default-script2
FAIL: ld-scripts/default-script3
FAIL: ld-scripts/default-script4

These can easily be fixed by changing the test symbol values from
0x8000000 and 0x9000000 to 0x8000 and 0x9000 so they fit as 16-bit
symbol values.  From what I see, the choice of values is arbitrary.


FAIL: ld-scripts/empty-address-1
FAIL: ld-scripts/empty-address-2a
FAIL: ld-scripts/empty-address-2b

These tests need 0x2000000 changed to 0x2000 and .long changed to
.word as mentioned for other tests, but here there may be a real bug
that needs to be fixed.  The tests are checking whether symbols are
defined various ways in a linker script have the correct value.  In
the pdp11 target, the symbols are undefined which suggests some
problem with inserting symbols from a linker script into the output
symbol table.  I don't know the code well enough to have an idea where
that problem might be.


FAIL: ld-scripts/pr14962
FAIL: ld-scripts/pr14962-2
FAIL: ld-scripts/pr22267

Additional instances of symbols in a linker script showing as
undefined in the output.


FAIL: ld-scripts/pr18963

This one is more complicated.  Starting with data.o consisting on only
a header and zero-length text, data and bss the linker script creates
sections that are each 0x10000 long with symbols corresponding to the
section addresses just to test whether addition is commutative using
those symbols.  The output generated by that linker script is much
larger than indicated by the a.out header (and several times larger
than the 16-bit address space) making the format invalid, so nm gives
an error.  Unless the test could be implemented with sections created
in the object file and just have the symbols defined in the linker
script based on those sections, this test is not supported for
pdp11-aout.


FAIL: MEMORY
FAIL: MEMORY with symbols

These scripts fail for two reasons:

1) The sizes of the text and data sections are too large to fit
together in a 16-bit address space, so the resulting symbol values
masked to 16 bits don't match the expected result.  I believe these
sizes could be reduced without affecting the test.

2) Symbol values with the 0x8000 bit set get sign-extended to 64 bits
in the output of nm, so again they don't match the expected output.
This sign extension is caused by the following statement in
bfd/pdp11.c function NAME (aout, translate_symbol_table):

      in->symbol.value = GET_SWORD (abfd,  ext->e_value);

That line is as written when the PDP11 target was added in 2001.
Since addresses are inherently unsigned, why is sign-extension
appropriate?  There may be offsets that require the result to wrap
around, but all arithmetic on addresses should be masked to the
number of address bits after the arithmetic operation.

Both of these causes could be avoided simply by reducing the numbers
in the test so that the results are all less than 0x8000, but I belive
the sign extension is a separate bug.

                                                        -- Steve