* Help with debugging coff .cset bug?
@ 2002-07-17 15:25 Jason Sullivan
2002-07-19 3:35 ` Alan Modra
2002-07-22 4:19 ` Nick Clifton
0 siblings, 2 replies; 5+ messages in thread
From: Jason Sullivan @ 2002-07-17 15:25 UTC (permalink / raw)
To: binutils
[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]
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).
I've done some stumbling around with gdb and printfs, and have found out
that the error happens after read_a_source_file(), but before
write_object_file(). I'm guessing this isn't much of a surprise, but I
suppose it's good to check the easy things first. What I'm looking for is
a pointer to where the problem might be (an out and out fix would be cool
to). Anyone out there have any suggestions?
The attached files will generate the bug with the following command run
with the above cofigured assembler...
as-new -m booke -al -o assem_test3.o assem_test3.as > assem_test3.lst
(See attached file: assem_test3.as)(See attached file: assem_test3.lst)(See
attached file: assem_test3.o)
--
Jason M. Sullivan
PowerPC Embbedded Processor Solutions
IBM Microelectronics
jasonsul@us.ibm.com (919.543.5650)
[-- Attachment #2: assem_test3.as --]
[-- Type: application/octet-stream, Size: 405 bytes --]
.globl __start
.globl .__start
.csect .data[DS]
__start:
.long .__start
nop
.long 0x11111111
nop
.long 0x11111111
nop
.long 0x11111111
.csect .text[pr]
.long 0x22222222
nop
.long 0x22222222
nop
.csect .__third[rw]
.long 0x33333333
nop
.long 0x33333333
nop
.align 4
.long 0x44444444
nop
.long 0x44444444
nop
[-- Attachment #3: assem_test3.lst --]
[-- Type: application/octet-stream, Size: 2256 bytes --]
[-- Attachment #4: assem_test3.o --]
[-- Type: application/octet-stream, Size: 478 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Help with debugging coff .cset bug?
2002-07-17 15:25 Help with debugging coff .cset bug? Jason Sullivan
@ 2002-07-19 3:35 ` Alan Modra
2002-07-22 4:19 ` Nick Clifton
1 sibling, 0 replies; 5+ messages in thread
From: Alan Modra @ 2002-07-19 3:35 UTC (permalink / raw)
To: Jason Sullivan; +Cc: binutils
On Wed, Jul 17, 2002 at 06:18:28PM -0400, Jason Sullivan wrote:
> 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).
Hi Jason,
You don't say what you consider the correct behaviour, at least not
explicitly. I'll assume that you expect the third csect to start from
zero. Is that so? From what I've read about csects they appear to
behave more or less like ELF sections, so that would be reasonable.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Help with debugging coff .cset bug?
2002-07-17 15:25 Help with debugging coff .cset bug? Jason Sullivan
2002-07-19 3:35 ` Alan Modra
@ 2002-07-22 4:19 ` Nick Clifton
1 sibling, 0 replies; 5+ messages in thread
From: Nick Clifton @ 2002-07-22 4:19 UTC (permalink / raw)
To: Jason Sullivan; +Cc: binutils
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Help with debugging coff .cset bug?
@ 2002-07-31 15:24 Jason Sullivan
0 siblings, 0 replies; 5+ messages in thread
From: Jason Sullivan @ 2002-07-31 15:24 UTC (permalink / raw)
To: Nick Clifton; +Cc: binutils
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
jasonsul@us.ibm.com (919.543.5650)
Nick Clifton
<nickc@redhat.com> To: Jason Sullivan/Raleigh/IBM@IBMUS
Sent by: cc: binutils@sources.redhat.com
binutils-owner@sources Subject: Re: Help with debugging coff .cset bug?
.redhat.com
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
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Help with debugging coff .cset bug?
@ 2002-07-19 7:50 Jason Sullivan
0 siblings, 0 replies; 5+ messages in thread
From: Jason Sullivan @ 2002-07-19 7:50 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils, binutils-owner
Yep, I expect all the sections to start at address 0 (at least before I run
it through a linker).
--
Jason M. Sullivan
PowerPC Embbedded Processor Solutions
IBM Microelectronics
jasonsul@us.ibm.com (919.543.5650)
Alan Modra
<amodra@bigpond.net.au To: Jason Sullivan/Raleigh/IBM@IBMUS
> cc: binutils@sources.redhat.com
Sent by: Subject: Re: Help with debugging coff .cset bug?
binutils-owner@sources
.redhat.com
07/19/02 06:09 AM
On Wed, Jul 17, 2002 at 06:18:28PM -0400, Jason Sullivan wrote:
> 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).
Hi Jason,
You don't say what you consider the correct behaviour, at least not
explicitly. I'll assume that you expect the third csect to start from
zero. Is that so? From what I've read about csects they appear to
behave more or less like ELF sections, so that would be reasonable.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-07-31 21:36 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-07-17 15:25 Help with debugging coff .cset bug? Jason Sullivan
2002-07-19 3:35 ` Alan Modra
2002-07-22 4:19 ` Nick Clifton
2002-07-19 7:50 Jason Sullivan
2002-07-31 15:24 Jason Sullivan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).