This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
IBM Microelectronics (919.543.5650)

                      Nick Clifton                                                                                                           
                      <>             To:      Jason Sullivan/Raleigh/IBM@IBMUS                                               
                      Sent by:                       cc:                                                    
                      binutils-owner@sources         Subject: Re: Help with debugging coff .cset bug?                                        
                      07/19/02 06:37 AM                                                                                                      

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

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 ?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]