This is the mail archive of the
mailing list for the binutils project.
Re: Help with debugging coff .cset bug?
- From: Nick Clifton <nickc at redhat dot com>
- To: "Jason Sullivan" <jasonsul at us dot ibm dot com>
- Cc: binutils at sources dot redhat dot com
- Date: 19 Jul 2002 11:37:26 +0100
- Subject: Re: Help with debugging coff .cset bug?
- References: <OF67167B62.62E0754A-ON85256BF9.firstname.lastname@example.org>
> 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-aix184.108.40.206 --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
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 ?