well i just find out if i move variable namestructs into the function ie making it private to funcion, code will compile ok.
so the only thing i can think of is something wrong with code segments/data segments or if we have this thing in arm,like code segment can not be read/write or...

anyway
regards,
roozbeh

____________________________________________________________________________________ No need to miss a message. Get email on-the-go
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail

well i am really going crazy.these c codes run ok
-------------------testpchar.c-------------
typedef struct
{

  char *name;

}
namestruct;

namestruct namestructs[1] =
{{"12345"}};

int findname (char *s)
{

return namestructs[0].name[1];
}
----------------main.c------------------
int main (int argc, char *argv[])
{
char s[]="s";
printf("start\n");
printf("%d \n",findname(s));
printf("end\n");
return 0;
}

output is :

start
50
end

and now the pascal code
{$apptype console}
{$link testpchar.o}
function findname (s : PChar) :
cardinal;cdecl;external name 'findname';
var
s:shortstring;
begin
writeln('start');
s:='s'#0#1;
writeln(findname(@s[1]));
writeln('end');
end.

output is
start
runtime error 216

and if i change the c code into
.
.
return namestructs[2].name[1];//ie change 0 into 2 .
.

output is
start
50
end

which is ok!
so whay exactly is wrong here,fpc compiler or evc compiler?!

____________________________________________________________________________________ Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097

From: "Roozbeh GHolizadeh"

Use debugger to find what instruction and where causes runtime error 216 which is access violation.

Yury.

well i am really going crazy.these c codes run ok

Use -Xe, this looks like a known bug of the elf linker with constant data sections.

Make the elf a coff ;)

Use -Xe, this looks like a known bug of the elf

linker with constant

data sections.

doing so i recieve sigsegv in setthreadpriority,bt shows this
(gdb) bt
#0 0x000112ec in SetThreadPriority ()
#1 0x00011270 in CreateThread ()
#2 0x00011270 in CreateThread ()
Previous frame identical to this frame (corrupt
stack?)

this is asm list file and where i get error with -Xi

; Function compile flags: /Odt
; File e:\fpc\projects\fribidi\cobj\test3\testpchar.c

AREA |.text|, CODE, ARM

|findname| PROC

; 12 : {

sub sp, sp, #4
|$M98|

; 13   :
; 14   : //return strcasecmp (namestructs[0].name);
; 15   :
; 16   : return namestructs[0].name[1];
	ldr       r0, [pc, #0x14]
	ldr       r1, [r0]
	ldrsb     r2, [r1, #1] //!!! here error!
	str       r2, [sp]
	ldr       r0, [sp]

; 17 : }

add sp, sp, #4
mov pc, lr

Use -Xe, this looks like a known bug of the elf

linker with constant

data sections.

and what we can do about this known bug?

____________________________________________________________________________________ We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265

the line from .asm file of evc shows this
ldr r0, [pc, #0x14]
and debugging with evc it is the same.but with fpc and gdb it is
ldr r0, [pc, #0x20]

so i guess problem is here!

____________________________________________________________________________________ Get your own web address.
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

So any ideas a least what it could be related to?
i mean if i want to fix it what should i test/look for?
problem with alignment of segments or...?

i just tried to use fpc external linker with microsoft linker.and with some headaches creating 1300 line of /merge:this section=that section.(by the way why fpc creates this too much different sections?why not just put all code in .text?!)linked and created program now works.

So it seems the problem is related to gnu linker
script,and i think maybe this script concept is also used for internal linker too,so both of them fail
linking correctly.

____________________________________________________________________________________ Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367

From: "Roozbeh GHolizadeh"
To:
Sent: Sunday, March 18, 2007 10:59 AM
Subject: [fpc-devel] Re: strange error with arm compiler whencompiling-running this code

So any ideas a least what it could be related to? i mean if i want to fix it what should i test/look for? problem with alignment of segments or...?

I think the problem is in different meaning of some relocs by ld and eVC linker.

FPC creates section for each procedure/variable. Each section has unique name and looks like .text.xxxxx

So it seems the problem is related to gnu linker script,and i think maybe this script concept is also used for internal linker too,so both of them fail linking correctly.

Please create bug report in mantis and attach eVC and pascal example code. I will take a look on it later.

Yury.

These sections are the basic infrastructure of smartlinking. If required can be disabled for the target in general. But then there will not be fast smartlinking available.

Peter

How?is there an option?
And if they are reuired why doesnt microsoft compiler produce that much sections?(or it does?)

http://lists.freepascal.org/mailman/listinfo/fpc-devel

____________________________________________________________________________________ Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/

Remove the tf_smartlink_sections flag for the target in i_*.pas

And if they are reuired why doesnt microsoft compiler produce that much sections?(or it does?)

I don't know what MS does. At least Borland also uses sections per function even in the TP ages inside the TPU/DCU. And for gcc there is -ffunction-section -fdata-sections and the --gc-sections for the linker (ld).

Peter