Help with debugging coff .cset bug?

[Nick Clifton]

Hi Jason,

> I'm making amusing attempts to debug a problem with .csect
> addressing in the gas assembler.  I've got it configured on AIX
> (--host=rs6000-ibm-aix4.3.3.0 --target=powerpc-ibm-aix) and Linux 
> (--host=i686-pc-linux-gnu --target=powerpc-ibm-aix), and I see the
> problem in both places.  When I look at the .lst file and dump the
> object file, the first and second .csects begin at the right address
> (0, since I haven't linked it), but the third .csect begins where
> the first one left off (so if the last address in the first section
> is 0x18, the first address of the third section will be 0x1c).

This may not be a bug.  I am not familiar with the PowerPC assembler,
but the source file gas/config/tc-ppc.c says:

  /* The .csect pseudo-op.  This switches us into a different
     subsegment.

In the same source file there is a function called 'ppc_change_csect'
which selects which section will hold a new .csect sub-section.  The
code can choose either the .text section or the .data section.  Hence
with your example code the first .csect is assigned to the .data
section (and hence gets an address of 0x0), the second .csect is
assigned to the .text section (and hence also gets an address of 0x0),
but the third .csect is assigned back to the .data section, so it is
placed after the first .csect and hence has a non-zero address.

This appears to be the correct behavior, so why do you think that it
is a bug ?

Cheers
        Nick