RE: Odd and Odder

[David Korn <dkorn at pixelpower dot com>]

>-----Original Message-----
>From: Stefan Petters [mailto:petters@lpr.e-technik.tu-muenchen.de]
>Sent: 08 March 2001 14:06

   Pardon me for interrupting at this stage, but...

>that is really strange. The compiler should either not use ``pea'', to
>push the string to the stack or use ``.ALIGN 4'' in the 
>.rodata section.

  Shouldn't all sections have a default alignment, generally 2 or 4, which
this entry (being the first entry in the .rodata section) would be aligned
to anyway?

>I beleave the second alternative as the correct one.
>You see below that the exception occurs at pea.l. 

  I'm confused:

>> from cpu32bug:
>> 
>> Exception: Address Error
>> Format/Vector=C00C
>> SSW=00D6  Fault Addr.=00090CB9  Data=00007FEC  Cur. PC=00090120  Cnt.
>> Reg.=0001
>> PC   =00090126 SR   =2704=TR:OFF_S_7_..Z..   VBR  =00000000
>> SFC  =5=SD     DFC  =5=SD     USP  =0000FC00 SSP* =00007FD4
>> D0   =00000000 D1   =01D6FFFF D2   =00000000 D3   =00000000
>> D4   =00000000 D5   =00000000 D6   =00000000 D7   =00000000
>> A0   =0000315E A1   =00003156 A2   =0000315A A3   =00000000
>> A4   =00000000 A5   =00000000 A6   =00007FF8 A7   =00007FD4
>> 00090126 48780000           PEA.L       ($0).W

..looks to me like the exception occurred at the instruction at 0x90120,
which is not the pea, but the jsr __main.  As long as the SP is aligned,
I don't see how ($0).W could be an unaligned address.

>       .file   "alcdtest.c"
> gcc2_compiled.:
> .globl __main
> .section        .rodata
> .LC0:
>       .string "12"
> .text
> .globl main
>       .type    main,@function
> main:
>       link.w %a6,#-260
>       jsr __main
>       pea .LC0
>       move.l %a6,%d0
>       add.l #-260,%d0
>       move.l %d0,-(%sp)
>       jsr strcpy
>       addq.l #8,%sp
> .L2:
>       unlk %a6
>       rts
> .Lfe1:
>       .size    main,.Lfe1-main
>       .ident  "GCC: (GNU) 2.95.2 19991024 (release)"

  Also, if that pea.l still has an address field of $0000 by the time
the code is being run, something is wrong: it looks like the instruction
hasn't been relocated.  Unless of course the .rodata section is really
getting mapped to location zero.  And the way it is using a .W (16-bit)
mode for calculating the effective address of .LC0 would suggest that the
.rodata section really is getting mapped to location zero.  That's strange,
unless your .rodata is normally used to set up the 68k exception vectors.

>As I have noted was as well in the code you did send me.
>The CPU32 book states (page 4-133):
>
>	Description: ... The effective address must be a long 
>word address.

  That's a new restriction that didn't apply to older 68k series, IIRC;
pea used to be a great way to calculate and push function arguments in one
go for something like a call 
     f (x + 3);


>> Now, if I change the string from "12" to "123", the program 
>does not bomb.

  Is it perhaps the case that the dummy __main is ending up in the .rodata
section also, and it isn't being properly aligned, so the length of the
string (which seems to be the first thing in .rodata) affects the alignment
of __main ?

-- 
 All your base are belong to us!


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com