linux – 遗留gcc编译器问题

linux – 遗留gcc编译器问题,第1张

概述我们正在使用基于 gcc 2.6.0的遗留编译器来交叉编译我们仍在使用的旧嵌入式处理器(是的,它自1994年以来一直在使用!).为这个芯片做gcc端口的工程师早就开始了.虽然我们可能能够从Web上的某个地方恢复gcc 2.6.0源代码,但该芯片的更改集已经完成 消失在企业历史的大厅里.直到最近,由于编译器仍在运行并生成可行的可执行文件,我们一直混淆不清,但是从 Linux内核2.6.25(以及2. 我们正在使用基于 gcc 2.6.0的遗留编译器来交叉编译我们仍在使用的旧嵌入式处理器(是的,它自1994年以来一直在使用!).为这个芯片做gcc端口的工程师早就开始了.虽然我们可能能够从Web上的某个地方恢复gcc 2.6.0源代码,但该芯片的更改集已经完成
消失在企业历史的大厅里.直到最近,由于编译器仍在运行并生成可行的可执行文件,我们一直混淆不清,但是从 Linux内核2.6.25(以及2.6.26)开始,它失败并显示消息gcc:虚拟内存耗尽…即使在没有参数的情况下运行或仅使用-v.我已经使用2.6.24内核重新启动了我的开发系统(从2.6.26开始)并且编译器再次工作(使用2.6.25重启不会).

我们有一个系统,我们保留在2.6.24只是为了为这个芯片做构建,但是感觉有点暴露,以防linux世界移动到我们不能再重建一个将运行的系统的程度编译器(即我们的2.6.24系统死了,我们无法在新系统上安装和运行2.6.24,因为某些软件部分不再可用).

有没有人对我们可以对更现代的安装做什么有任何想法,以使这个遗留的编译器运行?

编辑:

回答一些评论……

遗憾的是,这是我们芯片特有的源代码更改丢失了.这种损失发生在两个主要的公司重组和几个系统管理员(其中几个确实留下了一团糟).我们现在使用配置控制,但这对于这个问题来说太晚关闭了谷仓门.

使用VM是一个好主意,也可能是我们最终要做的事情.谢谢你的想法.

最后,我尝试了strace作为ephemIEnt建议并发现最后一次系统调用是brk(),它在新系统(2.6.26内核)上返回错误并在旧系统(2.6.24内核)上返回成功.这表明我真的用完了虚拟内存,除了tcsh“limit”在旧系统和新系统上返回相同的值,而/ proc / meminfo显示新系统有更多的内存和更多的交换空间.也许这是一个碎片问题或程序加载的地方?

我做了一些进一步的研究,并在内核2.6.25中添加了“brk randomization”,但是默认情况下会启用CONfig_COMPAT_BRK(禁用brk随机化).

编辑:

好的,更多信息:
它真的看起来像brk随机化是罪魁祸首,传统的gcc正在调用brk()来改变数据段的结束而现在失败,导致传统的gcc报告“虚拟内存耗尽”.有一些记录的方法可以禁用brk随机化:

> sudo echo 0>的/ proc / SYS /内核/ randomize_va_space
> sudo sysctl -w kernel.randomize_va_space = 0
>使用setarch i386 -R tcsh(或“-R -L”)启动新shell

我已经尝试了它们,它们确实有效,因为brk()返回值与没有它们(并且在内核2.6.25和2.6.26上都试过)不同(并且总是相同),但是brk()仍然失败,所以传统的gcc仍然失败:-(.

此外,我已将vm.legacy_va_layout = 1和vm.overcommit_memory = 2设置为无变化,并且已使用保存在/etc/sysctl.conf中的vm.legacy_va_layout = 1和kernel.randomize_va_space = 0设置重新启动.仍然没有变化.

编辑:

在内核2.6.26(和2.6.25)上使用kernel.randomize_va_space = 0会导致strace legacy-gcc报告以下brk()调用:

brk(0x80556d4)= 0x8056000

这表明brk()失败了,但看起来它失败了,因为数据段已经超出了请求的范围.使用objdump,我可以看到数据段应该以0x805518c结束,而失败的brk()表示数据段当前以0x8056000结束:

Sections:IDx name          Size      VMA       LMA       file off  Algn  0 .interp       00000013  080480d4  080480d4  000000d4  2**0                  CONTENTS,ALLOC,LOAD,Readonly,DATA  1 .hash         000001a0  080480e8  080480e8  000000e8  2**2                  CONTENTS,DATA  2 .dynsym       00000410  08048288  08048288  00000288  2**2                  CONTENTS,DATA  3 .dynstr       0000020e  08048698  08048698  00000698  2**0                  CONTENTS,DATA  4 .rel.bss      00000038  080488a8  080488a8  000008a8  2**2                  CONTENTS,DATA  5 .rel.plt      00000158  080488e0  080488e0  000008e0  2**2                  CONTENTS,DATA  6 .init         00000008  08048a40  08048a40  00000a40  2**4                  CONTENTS,CODE  7 .plt          000002c0  08048a48  08048a48  00000a48  2**2                  CONTENTS,CODE  8 .text         000086cc  08048d10  08048d10  00000d10  2**4                  CONTENTS,CODE  9 .fini         00000008  080513e0  080513e0  000093e0  2**4                  CONTENTS,CODE 10 .rodata       000027d0  080513e8  080513e8  000093e8  2**0                  CONTENTS,DATA 11 .data         000005d4  08054bb8  08054bb8  0000bbb8  2**2                  CONTENTS,DATA 12 .ctors        00000008  0805518c  0805518c  0000c18c  2**2                  CONTENTS,DATA 13 .dtors        00000008  08055194  08055194  0000c194  2**2                  CONTENTS,DATA 14 .got          000000b8  0805519c  0805519c  0000c19c  2**2                  CONTENTS,DATA 15 .dynamic      00000088  08055254  08055254  0000c254  2**2                  CONTENTS,DATA 16 .bss          000003b8  080552dc  080552dc  0000c2dc  2**3                  ALLOC 17 .note         00000064  00000000  00000000  0000c2dc  2**0                  CONTENTS,Readonly 18 .comment      00000062  00000000  00000000  0000c340  2**0                  CONTENTS,ReadonlySYMBol table:no symbols

编辑:

回应ephemIEnt的评论如下:“将GCC视为没有来源的二进制文件非常奇怪”!

因此,使用strace,objdump,gdb和我对386汇编程序和体系结构的有限理解,我已经将问题追溯到遗留代码中的第一个malloc调用.传统的gcc调用malloc,它返回NulL,导致stderr上的“虚拟内存耗尽”消息.这个malloc在libc.so.5中,它调用getenv
一堆次并最终调用brk()…我想增加堆…失败了.

从此我只能推测问题不仅仅是brk随机化,或者我还没有完全禁用brk随机化,尽管randomize_va_space = 0和legacy_va_layout = 1 sysctl设置.

解决方法 将旧的gcc安装到虚拟机上. 总结

以上是内存溢出为你收集整理的linux – 遗留gcc编译器问题全部内容,希望文章能够帮你解决linux – 遗留gcc编译器问题所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/1046039.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-05-24
下一篇 2022-05-24

发表评论

登录后才能评论

评论列表(0条)

保存