[Fwd: Odd and Odder]

[Joel <joel_Schantz at yahoo dot com>]

Joel wrote:
> 
> Mark:
> 
> Take a look at your memory map. You'll probably find that section .rodata starts on an odd numbered
> address when it fails.
> 
> This is happening because of where your linker script puts that section.
> (a function of what has occurred in memory in previous sections)
> 
> Take a look the ALIGN instruction under ld
> 
> I think if you added a
>         . = ALIGN(0x4);
> 
> before the
>         *(.rodata)
> 
> in your linker command that "May" fix your problem.
> 
> This will cause the .rodata to be aligned on a long word boundary
> 
> --      joel
> 
> Mark Palmerino wrote:
> >
> > Again, many thanks to everyone who offered suggestions for the problem I'm
> > running into.
> >
> > I've tried many of them and now have one piece of "odd" information that I
> > don't quite understand what to do with, but I'm hoping someone will. Also,
> > what I thought worked before (e.g., char const) doesn't work all the time -
> > read on for more details.
> >
> > Quick Problem Description: References to strings in the following fashion
> > cause the program to bomb:
> > strcpy(stringVar, "this is text");
> > lcd_print("this is text");
> >
> > Here is a summary of the ideas (and please forgive me if I didn't fully
> > understand some of them):
> >
> > 1. Jim Bates (and others): check where strings are being stored. Also, try
> > -traditional and -fwritable-strings
> > 2. Stefan Peters: take a look at the assembler code to see what makes things
> > different (i.e., the times when it works, and the times when it doesn't).
> > Specifically, check on the 'alignment of the data'.
> > 3. Yves Rutschle: had some ideas about why the code was working when I
> > included a printf
> > 4. Jay Kulpinski: try -fno-writable-strings, also check where the strings
> > get stored (might have to change linker script to get them into .rodata
> > section).
> >
> > (Again, please forgive me if I either misrepresented anyone's suggestion or
> > missed a suggestion!)
> >
> > I see two themes here - first, check the assembly output and second, try
> > different compilation flags.
> >
> > I have tried a few things. Before I go into a more detailed explanation, I
> > did find the following in my experiments:
> >
> > If the referenced string is an odd number of characters, the program does
> > *not* bomb.  For example, the following works:
> >
> > lcd_print("123");
> >
> > And the following does not work:
> >
> > lcd_print("12");
> >
> > The following works:
> >
> > lcd_print("12\0");  //That's a backslash-zero for a Null, is interpreted as
> > 1 char
> >
> > And the following does not work:
> >
> > lcd_print("123\0");
> >
> > I'm guessing this gives credence to this being an 'alignment' problem.
> > Unfortunately, I don't know what to do about it.
> >
> > Here is a simple test c program:
> >
> > #include <string.h>
> > #include <stdio.h>
> >
> > int main(void) {
> >       int i;
> >       char someText[256];
> >
> >       strcpy(someText,"12");
> > }
> >
> > and here is the assembly that is produced by m68k-elf-gcc -S test.c
> >
> >       .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)"
> >
> > When compiled and downloaded, this program bombs with the following output
> > 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
> >
> > Now, if I change the string from "12" to "123", the program does not bomb.
> >
> > I tried compiling with -fno-writable-strings and this made no difference.
> > Also, if I do the following with char const, the program bombs:
> >
> > char const footext[] = "12";
> > .
> > .
> > .
> > strcpy(someText,footext);
> >
> > However, building the string up in the following manner, does work
> > regardless of the number of characters that end up in the string:
> >
> > int main(void) {
> >       int i;
> >       char someText[256];
> >       char footext[256];
> >
> > footext[0] = '1';
> > footext[1] = '2';
> > footext[2] = '3';
> > footext[3] = '4';
> > footext[4] = '\0';
> >
> >       strcpy(someText,footext);
> > }
> >
> > So, with this new information, does anyone have any ideas for how to fix the
> > problem?
> >
> > Again, many, many thanks!
> >
> > ------
> > Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> > Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.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