【问题标题】:Raw binary file generated by objcopy is too bigobjcopy 生成的原始二进制文件太大
【发布时间】:2013-10-01 21:18:43
【问题描述】:

已阅读此内容,但无法解决我的问题。

huge binary files with objcopy

对于一些测试需要。 链接时我必须添加以下链接脚本。

.section_test 0x11323000: {  *(.section_test) }

这个自定义段必须从一个大地址0x11323000开始。

然后使用 objcopymips 生成原始二进制文件

objcopymips -O binary vxWorks.st E0122.bin    

这一步会使最终的原始二进制文件 bin 文件太大。从 27MB 到超过 270MB。

这样它就无法加载到我们只有大约 64MB 物理内存的机器上。

我可以在不删除任何部分的情况下减小它的大小并让它仍然可以执行吗?

【问题讨论】:

    标签: c gcc linker binary mips


    【解决方案1】:

    objcopy -O binary 根据段的加载地址生成程序的内存映像。在您的情况下,.section_test 的加载和运行时地址是相同的,即加载地址是 0x11323000,这说明了大文件大小。

    通常的解决方案是创建一个带有紧凑加载映像的可执行文件,并让程序自己在使用之前将必要的部分从加载地址复制到运行时地址。

    例子:

    .section_test 0x11323000 : AT(some-small-address) {  *(.section_test) }
    

    .section_test 0x11323000 : {  *(.section_test) } AT> some-region-name
    

    也请检查此页面: https://sourceware.org/binutils/docs/ld/Output-Section-LMA.html#Output-Section-LMA

    【讨论】:

    • 完美答案,非常感谢!我之前检查过这本手册,但错过了这部分......
    • 我明白答案,但是为什么bss部分没有包含在大文件中? (在上面链接的示例中) - bss 部分没有“AT”
    猜你喜欢
    • 1970-01-01
    • 2011-07-11
    • 2017-07-19
    • 2021-12-13
    • 1970-01-01
    • 2020-09-25
    • 1970-01-01
    • 2020-12-08
    • 1970-01-01
    相关资源
    最近更新 更多