RE: Assertion in gas/tc_gen_reloc in dlx-elf, arc-elf, perhaps other targets under some conditions

["Dave Korn" <dk at artimi dot com>]

> -----Original Message-----
> From: Nick Clifton
> Sent: 03 March 2004 12:56
> To: Dave Korn

> The first thing to do is to submit this test as an addition 
> to the GAS testsuite.  The assembler should definitely cope 
> with such code gracefully, rather than triggering an internal assert.

  I've got a .s file that triggers it but don't know what to write in the .d
file yet.  Attached.

> >   To sum it up, the problem seems to me to be that 
> fixup_segment does 
> > something broken, by setting the fx_pcrel flag without 
> adjusting the 
> > fx_r_type to correspond to a pc-relative reloc type.
> 
> > But maybe it simply shouldn't be trying to make the fixup 
> pc relative 
> > at all when the sum and difference symbols come from different 
> > sections?
> 
> Yes - I think that this is the right approach.  For example 
> please try the patch below and let me know what you think.
> 
> Cheers
>         Nick
> 
> gas/ChangeLog
> 2004-03-03  Nick Clifton  <nickc@redhat.com>
> 
> 	* write.c (fixup_segment): Do not convert a fixup to be
> 	pc-relative if it involves two symbols in different sections.


  Well, what I get with that is lots of errors, which is better than
assertions I guess:

../as-new   -o dump.o
/repository/dlxtools/binutils/gas/testsuite/gas/dlx/jtab.s
/repository/dlxtools/binutils/gas/testsuite/gas/dlx/jtab.s: Assembler
messages:
/repository/dlxtools/binutils/gas/testsuite/gas/dlx/jtab.s:8: Error: can't
resolve `.text' {.text section} - `.L13' {.rodata section}
/repository/dlxtools/binutils/gas/testsuite/gas/dlx/jtab.s:9: Error: can't
resolve `.text' {.text section} - `.L13' {.rodata section}
/repository/dlxtools/binutils/gas/testsuite/gas/dlx/jtab.s:10: Error: can't
resolve `.text' {.text section} - `.L13' {.rodata section}
FAIL: jtab


  Hmm, I'm not sure now.  

  Given that the subsy is in the same section as the reloc, so we can know
the delta between them at assembly time, there's nothing intrinsically
impossible about leaving the addsy to be handled by a final link reloc and
having the subsy encoded in the addend or even in the insn itself, isn't it?

  IOW it's basically doing the right thing in trying to make it pc-relative,
but it needs to adjust fx_r_type to tell the backend what it's done?

  Or should I just be looking at the comment a few lines further down from
your patch:

	      /* Make it pc-relative.  If the back-end code has not
		 selected a pc-relative reloc, cancel the adjustment
		 we do later on all pc-relative relocs.  */

and make the backend choose a pc-relative reloc in the first place in this
case?


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Attachment: assert-gas-diff.txt
Description: Text document