This is the mail archive of the
mailing list for the binutils project.
Re: Help with debugging coff .cset bug?
- From: "Jason Sullivan" <jasonsul at us dot ibm dot com>
- To: Nick Clifton <nickc at redhat dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Wed, 31 Jul 2002 17:36:22 -0400
- Subject: Re: Help with debugging coff .cset bug?
Sorry for the long delay in replying, but I had to do a little research in
my copious free time :-).
It's mostly because that's the way our old assembler did (or claimed to do)
entry points. However, in perusing the documentation for the old assembler
(and some documentation on XCOFF), It seems that we were doing it wrong
(how or why it actually worked eludes me right now). So a little
assembler writing to remove the extra .csect from our code was what was
needed. Sorry for the false alarm.
Jason M. Sullivan
PowerPC Embbedded Processor Solutions
<firstname.lastname@example.org> To: Jason Sullivan/Raleigh/IBM@IBMUS
Sent by: cc: email@example.com
binutils-owner@sources Subject: Re: Help with debugging coff .cset bug?
07/19/02 06:37 AM
> 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-aix22.214.171.124 --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 ?