[parisc-linux] internal error in tc-hppa.c?

[parisc-linux] internal error in tc-hppa.c?

[Grant Grundler]

Hi all,
I crashed the assembler with the following output:

make[1]: Entering directory `/linux/kwdb64/linux-2.3/arch/parisc64/kernel'
hppa64-linux-gcc -I/linux/kwdb64/linux-2.3/include   -D__KERNEL__ -I/linux/kwdb64/linux-2.3/include  -c -o entry.o entry.S
entry.S: Assembler messages:
entry.S:1: Internal error, aborting at /linux/pa32/binutils-2.10/gas/config/tc-hppa.c line 4017 in tc_gen_reloc
Please report this bug.
make[1]: *** [entry.o] Error 1
make[1]: Leaving directory `/linux/kwdb64/linux-2.3/arch/parisc64/kernel'


I was told entry.S is broken but the assembler should handle it
more gracefully...so I'll be looking at entry.S to see what's broken.

Line number of entry.S is junk since parisc64 version is just
an include of the parisc version. line 1560 is the real culprit:
        b,n .

Trying to figure out what the problem is now...

grant

Re: [parisc-linux] internal error in tc-hppa.c?

[Grant Grundler]

Grant Grundler wrote:
...
> I was told entry.S is broken but the assembler should handle it
> more gracefully...so I'll be looking at entry.S to see what's broken.
> 
> Line number of entry.S is junk since parisc64 version is just
> an include of the parisc version. line 1560 is the real culprit:
>         b,n .

More data:
o adding a NOP didn't help.
o slightly older hppa64-linux tool chain can build the same file.
o looking at line 4017 of tc-hppa.c suggests hppa_gen_reloc_type() failed.

I'll continue using the older toolchain...

grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] internal error in tc-hppa.c?

[Grant Grundler]

Grant Grundler wrote:
> o slightly older hppa64-linux tool chain can build the same file.

Both 20000915 or 20000921 toolchains die with the same problem.
So I couldn't reproduce what I stated above.

Back too looking at entry.S file and it's include files...<sigh>

grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] internal error in tc-hppa.c?

[Grant Grundler]

Grant Grundler wrote:

> I was told entry.S is broken but the assembler should handle it
> more gracefully...so I'll be looking at entry.S to see what's broken.

This was correct - in a twisted sense (tnx dhd!).
Case closed. Details and minor rant follow.


> Line number of entry.S is junk since parisc64 version is just
> an include of the parisc version. line 1560 is the real culprit:
>         b,n .

This is the last line of the file...adding NOP moved the error
to the nop.


The problem was the following change to arch/parisc/tools/offset.c:

| revision 1.9
| date: 2000/09/22 13:36:58;  author: jsm;  state: Exp;  lines: +12 -1
| Put in offset for processor field in task structure. Put in offset for
| elements of irq_cpustat_t which are used in assembly for processing
| software interrupts.

It was NOT ported to arch/parisc64/tools/offset.c.

jsm added TASK_PROCESSOR definitions *and* used them in entry.S.
entry.S is common between parisc and parisc64 while offset.c is not.

[/rant on]
Having to track this down the hard way cost me ~3 hours.
Especially since Paul Bame and I were suspicious about
our recent changes to assembly.h...so if the error reported
could be more informative (ie which symbol failed),
it'd have been easy to figure out.
{/rant off]

Could someone who has a clue about tc-hppa.c improve the
error reporting for this case?
I'm certain we are going to see this again...

thanks,
grant

ps. I've ported the changes to parisc64/tools/offset.c and
   will commit them shortly.

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] internal error in tc-hppa.c?

[Alan Modra]

On Fri, 22 Sep 2000, Grant Grundler wrote:

> Could someone who has a clue about tc-hppa.c improve the
> error reporting for this case?
> I'm certain we are going to see this again...

OK, it's fairly easy to make gas report symbols associated with fixups
that it doesn't understand.  I'll look at it in a few hours - I'm off to
pick up a new car :)

This sort of bug is due to gas originally being written just to process
gcc output.  ie. gas lays no claim to being a general purpose assembler.
x86 gas had the same sort of behaviour a few years ago, and you might be
surprised to know I met with some resistance to making x86 gas more
general purpose.

Alan Modra
-- 
Linuxcare.  Support for the Revolution.