From: Eiler, James A. (James.Eiler@alcoa.com)
Date: Fri Sep 10 2004 - 16:06:14 EDT
Original posting at the end...
Thanks to James Sainsbury and Bob Harris for their replies.
Both suggested line ordering as the root "problem" and James gave a very detailed response:
It's probably not obvious but the compiler can and does rearrange
code sequences.
ie
the code generated for source line `n+k' can precede that for line `n'
cc -S and dis are useful here.
The problem seems to be that you have set a breakpoint at line 12
and branched to line 14 (jumping over line 13 - which in source is empty).
The sequence
stop at 12
run
next
doesn't produce an exception.
Looking at the .o file - stopping before line 13 and starting after line 13
(ie line 15) would probably explain the observed problem
dis jaetest.o
main:
[jaetest.c: 5] 0x0: 27bb0001 ldah gp, 1(t12)
[jaetest.c: 5] 0x4: 23bd80c0 lda gp, -32576(gp)
[jaetest.c: 5] 0x8: 23defec0 lda sp, -320(sp)
[jaetest.c: 5] 0xc: b75e0018 stq ra, 24(sp)
[jaetest.c: 11] 0x10: 221e0028 lda a0, 40(sp)
[jaetest.c: 11] 0x14: a63d8028 ldq a1, -32728(gp)
[jaetest.c: 11] 0x18: 22310000 lda a1, 0(a1)
[jaetest.c: 11] 0x1c: a77d8020 ldq t12, -32736(gp)
[jaetest.c: 11] 0x20: 6b5b4000 jsr ra, (t12), strcpy
[jaetest.c: 11] 0x24: 27ba0001 ldah gp, 1(ra)
[jaetest.c: 11] 0x28: 23bd809c lda gp, -32612(gp)
# Break point here
[jaetest.c: 13] 0x2c: 47e03400 bis zero, 0x1, v0
[jaetest.c: 13] 0x30: b01e0020 stl v0, 32(sp)
[jaetest.c: 16] 0x34: 203e0028 lda t0, 40(sp)
[jaetest.c: 16] 0x38: 205e0028 lda t1, 40(sp)
[jaetest.c: 16] 0x3c: 207e0028 lda t2, 40(sp)
# Branched to here
[jaetest.c: 15] 0x40: b43e0000 stq t0, 0(sp)
[jaetest.c: 15] 0x44: b45e0008 stq t1, 8(sp)
[jaetest.c: 15] 0x48: b47e0010 stq t2, 16(sp)
[jaetest.c: 15] 0x4c: 221e0038 lda a0, 56(sp)
[jaetest.c: 15] 0x50: a63d8018 ldq a1, -32744(gp)
[jaetest.c: 15] 0x54: 22310000 lda a1, 0(a1)
[jaetest.c: 15] 0x58: 225e0028 lda a2, 40(sp)
[jaetest.c: 15] 0x5c: 227e0028 lda a3, 40(sp)
[jaetest.c: 15] 0x60: 229e0028 lda a4, 40(sp)
[jaetest.c: 15] 0x64: 22be0028 lda a5, 40(sp)
[jaetest.c: 15] 0x68: a77d8010 ldq t12, -32752(gp)
[jaetest.c: 15] 0x6c: 2ffe0000 ldq_u zero, 0(sp)
[jaetest.c: 15] 0x70: 6b5b4000 jsr ra, (t12), sprintf
[jaetest.c: 15] 0x74: 27ba0001 ldah gp, 1(ra)
[jaetest.c: 15] 0x78: 23bd804c lda gp, -32692(gp)
[jaetest.c: 18] 0x7c: 47ff0400 bis zero, zero, v0
[jaetest.c: 18] 0x80: a75e0018 ldq ra, 24(sp)
[jaetest.c: 18] 0x84: 23de0140 lda sp, 320(sp)
[jaetest.c: 18] 0x88: 6bfa8001 ret zero, (ra), 1
[jaetest.c: 18] 0x8c: 00000000 call_pal halt
RGDS
Original Posting:
On Thu, 12 Aug 2004, Eiler, James A. wrote:
> All,
>
> I've tried the following on several Alphas with different versions of T64 (4.0G, 5.1A, 5.1B) (and different versions of dbx and ladebug) and got the same result every time.
>
> My little C program is as follows:
>
> 1 #include <stdio.h>
> 2 #include <string.h>
> 3
> 4 main( )
> 5 {
> 6 char sName [ 16 ];
> 7 char sString[ 256 ];
> 8 int iStatus;
> 9
> 10 strcpy( sName, "bar" );
> 11
> 12 iStatus = 1;
> 13
> 14 sprintf( sString, "%s %s %s %s %s %s %s",
> 15 sName, sName, sName, sName, sName, sName, sName );
> 16
> 17 }
>
>
> If I compile it and run it with the debugger (dbx or ladebug), set a breakpoint at line 12, then run it to the breakpoint, then goto line 14, then do a next, I get a segmentation violation:
>
> alpha1-mst> cc jaetest.c -g2 -o jaetest
> alpha1-mst> dbx jaetest
> dbx version 5.1
> Type 'help' for help.
>
> main: 10 strcpy( sName, "bar" );
> (dbx) b 12
> [2] stop at "jaetest.c":12
> (dbx) r
> [2] stopped at [main:12 ,0x12000118c] iStatus = 1;
> (dbx) goto 14
> (dbx) n
> signal Segmentation fault at >*[strlen, 0x3ff800d27e0] ldq_u t0, 0(a0)
>
> However, if I just run it (from the command prompt), it runs just fine.
>
> And if I run in from the debugger and just "next" through it, it also works just fine.
>
> Lastly, if I change the sprintf( ) to have less than 5 "%s" conversion strings, it also works just fine!
>
> I stumbled across this quite by accident while trying to debug one of my programs, and this is the essence of what I was running into.
>
> Has anyone seen anything like this before?
>
> Thanks!
>
> Jim
>
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:50:07 EDT