arm-elf-gcc编译时如何强制其使用长指针?

[skertone]

我用gcc编译一段代码，

bar(10,100,80,30);
puttextxy("这是测试AA!",10,10,0);

bar,与puttextxy都是在自已的操作系统中输出的函数

但以上代码执行到 puttextxy出错,愿因是第一个参数传的Address不对

第一个参数传给操作系统的是 16位指针即用"%p"打印 = 0x0000966C

用以下代码

char buf[10];

buf[0] = 'T';
buf[1] = 'E';
buf[2] = 'S';
buf[3] = 'T';
buf[4] = '\0';
puttextxy(buf,10,10,0);

可以正常执行，传入操作系统的第一个参数是 32位指针 即打印 "%p" = 0x81008432(注:0x81000000是我ld时指定的起始地址)

由于在C代码中使用字符串常量编译后均会调用操作系统 memcpy
同上传入的都将会是16位指针导致不能正常运行

请问怎么令GCC在对所有指针强制采用32位指针啊，

以前学C语言的far 关键词在gcc中是不能用的.

[linuxguy]

>>>由于在C代码中使用字符串常量编译后均会调用操作系统 memcpy
>>>同上传入的都将会是16位指针导致不能正常运行

有这种事? 16位指针? MARK!

[lionc650]

啥意思？在32位系统下指针不都是32的吗？

char buf[10];

buf[0] = 'T';
buf[1] = 'E';
buf[2] = 'S';
buf[3] = 'T';
buf[4] = '\0';
puttextxy(buf,10,10,0);
这个buf难道不是32位的吗？？

ps，我太懂 arm-elf，不知道这和普通的gcc有啥区别.....

[skertone]

[Quote=引用 1 楼 linuxguy 的回复:]
>>>由于在C代码中使用字符串常量编译后均会调用操作系统 memcpy
>>>同上传入的都将会是16位指针导致不能正常运行

有这种事? 16位指针? MARK!
[/Quote]

是的，调用字符串常量时传给被调函数的指针是“短指针”只有 16位有效地址
但是，调用数组时传给被调函数的指针是 32位有效地址的“长指针”

在代码中如果给字串初始化，如：

char str[100] = "TEST!";

编译器将编译成(可以通过编译后的汇编代码查看)
char str[100];
memcpy(str,"TEST!",5);

这样传给memcpy 的 str 指针长度虽是32位但有效地址却只有16位，

因为在我的系统中应用程序是从0x81000000地址开始的

[skertone]

[Quote=引用 2 楼 lionc650 的回复:]
啥意思？在32位系统下指针不都是32的吗？

char buf[10];

buf[0] = 'T';
buf[1] = 'E';
buf[2] = 'S';
buf[3] = 'T';
buf[4] = '\0';
puttextxy(buf,10,10,0);
这个buf难道不是32位的吗？？

ps，我太懂 arm-elf，不知道这和普通的gcc有啥区别.....
[/Quote]

我想在这个方面 arm-elf-gcc 跟 gcc应该没差别
系统是32位的，所有指针长度都是32位，前面说的不是很清楚，应该是有效地址的不同

调用字符串常量时 字串常量地址是 0x81001234 传到被调函数里地址为 0x00001234
调用数组时正常 假设数组地址是 0x81004567 传到被调函数里仍然为 0x81004567

我想知道如何强制让编译器在使用字串常量时传完整的“长地址”

[linuxguy]

>>>因为在我的系统中应用程序是从0x81000000地址开始的
你怎么设定的?
还有数组都是利用stack动态分配的, 难道你stack起始地址是810000000?

char str[100] = "TEST!"; 这种定义确实和
buf[0] = 'T';
buf[1] = 'E';
buf[2] = 'S';
buf[3] = 'T';
buf[4] = '\0';
这种的确分配地址方式不同.一个是放到数据段, 一个是存储到stack

[skertone]

[Quote=引用 5 楼 linuxguy 的回复:]

>>>因为在我的系统中应用程序是从0x81000000地址开始的
你怎么设定的?
还有数组都是利用stack动态分配的, 难道你stack起始地址是810000000?

char str[100] = "TEST!"; 这种定义确实和
buf[0] = 'T';
buf[1] = 'E';
buf[2] = 'S';
buf[3] = 'T';
buf[4] = '\0';
这种的确分配地址方式不同.一个是放到数据段, 一个是存储到stack
[/Quote]

确实如此，实际栈顶是 STACKS 0x8103b800 ，以上例举的地址只是示意

如果能使gcc编译的代码调用数据段常量时使用“32位长地址”就解决问题了

[gogofly_lee]

LZ 是用arm-elf-gcc 来编译的吗？可以考虑换成arm-linux-gcc编译试试，看是否有同样的问题。
尽管这两编译器差不多，但是它们在预处理和使用库时不一样，arm-elf-gcc 主要针对Uclinux的。

[skertone]

感谢 linuxguy 的提醒

问题最终还不是地址长度问题，是.text段起始竟是 0x00000000 所以看起像传了 16位Address

我用 ad 指令查看 发现 Section .text 地址不是0x81000000

链接参数里加 -Ttext 0x81000000 解决

ld -EL -nostdlib -nostartfiles --no-omagic --oformat elf32-littlearm -e0x81000000 -Ttext 0x81000000 ....