Re: Proposed changes for pdp11 --*magic options

[Nick Clifton <nickc@redhat.com>]

Hi Stephen,

> 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?

Sorry - it is just a local comparison.

>  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?

Exactly.  I am fairly confident that most of them can be XFAILed,
but I prefer to add a comment explaining why the XFAIL is there,
and for that I need to understand the reason for the failure.
(Actually, since I am not a PDP11 expert, I am hoping that somebody
else will do this for me...)

 
> ERROR: /Users/casner/epos/binutils/binutils-gdb/ld/testsuite/ld-misc/start.s: assembly failed

> 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?

Using .dc.a should work for all targets, so that is what I would recommend.

> 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.

Agreed.

> 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.

OK, then these should be left as FAIL results for now.


> 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.

This sounds like a reasonable case for an xfail, with a comment along
the lines of "this test creates a binary that is too big for 16-bit architectures".


> 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.

I would be inclined to say that this is a bug and change the 
macro to GET_WORD.  There are symbols whose value are not addresses
but their signed-ness is not known to the linker, so an unsigned
fetch should be safe.


> 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.

I would be happy to review a patch containing the changes you have suggested above...

Cheers
  Nick