Re: bug in gas from gcc code

[Nick Clifton]

Hi James,

> The optimization of (.-L132) is controlled by the following
> in expr.c:
> 
>       /* This case comes up in PIC code.  */
>       else if (op_left == O_subtract
>         && right.X_op == O_symbol
>         && resultP->X_op == O_symbol
>         && (symbol_get_frag (right.X_add_symbol)
>      == symbol_get_frag (resultP->X_add_symbol))
>         && SEG_NORMAL (rightseg))
>  {
>    resultP->X_add_number -= right.X_add_number;
>    resultP->X_add_number += (S_GET_VALUE (resultP->X_add_symbol)
>         - S_GET_VALUE (right.X_add_symbol));
>    resultP->X_op = O_constant;
>    resultP->X_add_symbol = 0;
>  }
> 
> For the first two lines, everything works, and we take the
> optimization.  For the third line (and then for the 4th),
> we have different fragments; the symbol_get_frag
> for the right and the resultP are not the same.  Presumably
> the reason we care about the fragments being the same is
> that if the two symbols are in different fragments, they are
> in different segments, and so can't be just subtracted.

Not quite, see below.

> 1. Why do we close the fragment and start a new one?

In the particular case you are describing we could grow the frag.  In
general however, frags are not grown because they are used to handle
the repositioning of data.

> 2. Why do we check if the fragments are the same, and not the
> sections, in expr.c, to decide if we can compute the difference
> in the assembler?

Because if the two symbols are in different frags their relative
locations cannot be computed.  Frags can be moved around (eg due to
relaxing), so the distance between two symbols in different frags,
even if they are in the same section, cannot be calculated.


> 3. Should we be generating these "invalid" segment error messages,

    .long .L127-.+4+(.-.L132)

     /tmp/ccK9l1qf.s:2992: Error: invalid section for operation

Why are they invalid ?  The .L132 symbol is in the .rodata section,
whereas the the .L127 et al symbols are in the text section.  Since
these are local symbols they (may) be omitted from the generated
object file, so generating a reloc for may not work.  In general any
computation involving local symbols should be resolvable at assemble
time or convertible into a relocation.

The real bug is that we are not generating the warning for the first
two entries in the switch table.

> And if it is an error -- how do we get gcc to generate correct code? 

I am not familiar with the x86-64 architecture, so I am not sure
exactly how this should be fixed.  One possibility is to put the
switch tables in the .text section (controlled by the definition of
READONLY_DATA_SECTION).

> The file /tmp/ccK9l1qf.s, generated by gcc, is attached.
> This is for an X86-64 assembly (the 64bit extension to x86
> from AMD).  I invoke gas with no parameters:
> 
>    /home/peterson/work/tc6/opt/x86-64/bin/x86_64-unknown-linux-as
> /tmp/ccK9l1qf.s

Unfortunately you appear to only have attached the name and the not
the file :-(  When I tried it with a simple test file like this:

---------------------------------------
        .section        .rodata
        .align 16
.L132:
        .long .L96-.+4+(.-.L132)
        .long .L105-.+4+(.-.L132)
        .long .L127-.+4+(.-.L132)
        .long .L130-.+4+(.-.L132)
        
        .section .text
.L96:
        nop
.L105:
        nop
.L127:
        nop
.L130:
        nop
---------------------------------------

The assembler coped just fine.  It converted the local references into
relocs off the .text section:

---------------------------------------
  % objdump -Dr fred.o

a.out:     file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <.text>:
   0:   90                      nop    
   1:   90                      nop    
   2:   90                      nop    
   3:   90                      nop    
Disassembly of section .data:
Disassembly of section .rodata:

0000000000000000 <.rodata>:
        ...
                        0: R_X86_64_PC32        .text
                        4: R_X86_64_PC32        .text+0x5
                        8: R_X86_64_PC32        .text+0xa
                        c: R_X86_64_PC32        .text+0xf
---------------------------------------

Cheers
        Nick