[Bug gas/24464] rx: Fatal error: Infinite loop encountered whilst attempting to compute the addresses of symbols in section P

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24464

--- Comment #2 from Nick Clifton <nickc at redhat dot com> ---
Hi Martin, Hi Richard,

  The assembler is struggling because the BNE instruction could be two
  different sizes.  It is trying to choose the smallest possible size
  for the instruction, but at the same time it is trying to honour the
  BALIGN directive and keep the fragment of code starting at .L7 aligned
  to a two byte boundary.

  In the end it bounces between two different possible values until the
  loop limit built in to the assembler kicks in.  Interestingly enough
  the RX backend for the assembler has code to handle this specific
  situation, but this only kicks in after 10 iterations of the relaxation
  code.  The infinite loop warning built in to the assembler's generic
  code is triggered after 2^N attempts, where N is the number of fragments
  of assembler in the source.  (For the purposes of this PR, fragments
  can be considered to be pieces of assembler separated by the .balign
  directive).  If the testcase were bigger, with more fragments in it,
  then the error message would not appear, because the RX backend's own
  code would be triggered before the generic code.

  I am uploading a patch which would fix this specific problem, but I
  do not think that it would be a good idea to apply it.  Overall, it
  will degrade the assembler's ability to reduce RX code size, for 
  large binaries, as it reduces the number of relaxation attempts.  Is
  this PR a real problem for you ?  If not then I would rather not 
  apply the patch.


(In reply to Richard Biener from comment #1)

> Btw, passing -relax to the assembler makes it assemble OK, producing

  The -relax option is a bit misleading.  What it does is to enable 
  link-time relaxation of the RX instructions, as opposed to 
  assembly-time relaxation.  So it has the effect of turning off (some
  of) the assembler's relaxation code, thus making the size of the two 
  fragments fixed, and hence preventing the problem.

> likewise writing bne.b instead of bne in the assembly.  That's odd
> since w/o the .balign and without -relax gas produces the same:

  Specifying a fixed size for the BNE instruction means that it cannot
  be relaxed, and hence the size of the fragment containing it is now
  constant, and so again the problem does not arise.

Cheers
  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.