Odd and Odder

Mark Palmerino mbp@csr-bos.com
Thu Mar 8 04:47:00 GMT 2001


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



More information about the crossgcc mailing list