This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
>-----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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |