【问题标题】:Microblaze & C++ | Why does the code size increase dramatically under certain conditions?Microblaze & C++ |为什么在某些情况下代码大小会急剧增加?
【发布时间】:2021-04-16 20:08:04
【问题描述】:

一年多来,我一直在使用 C++ 为 Microblaze 处理器开发嵌入式软件。我的设计并没有那么复杂,所以我没有使用该语言强大的、面向对象的特性。

一段时间以来,我一直在尝试增强我的设计结构。为此,我尝试广泛使用 C++ 的复杂特性,例如继承、多态等。作为新手,我相信单独使用继承不会影响代码大小。只有多态性有一些副作用,例如添加虚拟表指针、运行时类型信息等。我的问题始于向基类添加纯虚拟成员函数。

为了提供一个可运行的示例,我将尝试模仿我所面临的情况。

下面的代码编译并生成 13292 字节 的代码。这段代码不可能有这么多的指令。但是,我相信生成的 BSP 中的某些部分是在生成 elf 文件时必须包含的。

class Base{
public:
    Base() = default;
    ~Base() = default;
  
    virtual void func() {}
  
    int m_int;
};

class Derived : public Base{
public:
    Derived() = default;
    ~Derived() = default;
    
    void func() final {}
  
    int m_int2;
};

int main()
{
    Derived d;
  
    while(1);    
}
 

13KB 当您认为您有近 128KB 的可用 RAM 时,这并不算多。实际上,直到出现纯虚函数的问题时,我才注意到生成的代码的大小。下面的第二个代码具有相同的结构,除了 func() 现在是一个纯虚函数。构建此代码为我们提供了一个大于可用*(128KB)* RAM 大小的代码大小。因此,我修改了链接器文件以添加一些假 RAM,以便能够编译代码。编译成功后,生成的代码大小接近157KB!

class Base{
public:
    Base() = default;
    ~Base() = default;
  
    virtual void func() = 0;
  
    int m_int;
};

class Derived : public Base{
public:
    Derived() = default;
    ~Derived() = default;
    
    void func() final {}
  
    int m_int2;
};

int main()
{
    Derived d;
  
    while(1);    
}

我没有更改编译器的任何首选项,所有参数都处于默认状态。除了自动生成的库之外,没有其他库。您认为问题可能是什么?

一些补充说明

  • 我在两个不同的 IDE 上尝试了这些代码。 Vivado SDK 2017.2 和 Vitis 2019.2
  • 同样的问题也出现在动态分配调用(operator new 和 delete)上。用 C 风格的 malloc 和 free 替换它们可以解决问题。
  • 在发布模式下构建代码也解决了这个问题。在发布模式下,无论我是否使用纯虚函数,生成的代码都是 1900 字节。

如果需要,我可以提供更多信息,谢谢

我在 Xilinx 论坛上问过同样的问题,你可以找到它 here

【问题讨论】:

  • @NathanPierson 由于规则 No thread of execution can execute forever without performing any of these observable behaviors. 其中 “这些可观察的行为” 是不包括 null 语句的事物列表。
  • 链接器生成的 .map 文件应该详细说明哪些内存用于哪些组件。比较两个构建的 .map 文件。
  • 检查您的地图文件以查看包含的内容和大小。我刚刚在禁用优化的 ARMCC v6 上进行了尝试,它达到 1548 字节,包括启动代码。包含此代码的目标模块的代码只有 82 个字节。启用 RTTI 将大小增加到 3208,但对归因于此代码的 82 字节没有影响。在 -01 它减少到 46 个字节。我对 MicroBlaze 一无所知,但显然有问题。但如果还没有,请禁用 RTTI。
  • 比较来自调试和发布版本的地图文件,看看它添加了什么。
  • This question 谈到了 ARM 的类似行为。这个问题似乎与处理调用纯虚方法的可能性有关。

标签: c++ embedded xilinx microblaze


【解决方案1】:

解决方案有点令人毛骨悚然:) 在开始之前,特别感谢所有提供帮助的人。

简短回答

只需将以下代码段添加到您的主文件中:

extern "C" void __cxa_pure_virtual() { while(1); }

如果你也想解决operator newoperator delete相关的问题,也可以添加以下代码:

void* operator new(const std::size_t size) noexcept
{
    void* p = std::malloc(size);
    return p;
}

void operator delete(void* p) noexcept
{
    std::free(p);
}

详情

原来的解决方案是here。问题始于完全将 libstdc++ 拉出画面。这样我们就放弃了使用标准库函数的权利,所以我们应该提供我们自己的标准调用的实现,例如mallocnewfree等。即使你重新实现所有必需的调用,编译器也会抱怨缺少一个名为__cxa_pure_virtual() 的函数。这是最终解决方案的线索。

__cxa_pure_virtual 函数是一个在调用纯虚函数时调用的错误处理程序。我们可以很容易地说,我们从来没有做过这种愚蠢的尝试。但是,编译器从不信任任何软件开发人员:) 因此,当您编写包含纯虚函数的 C++ 代码时,编译器会隐式添加错误处理程序来处理潜在的运行时错误。您可以猜到,对于资源有限的系统(例如我们的 Microblaze)来说,这些调用成本很高。

因此,如果我们正在编写一个具有纯虚函数的 C++ 应用程序,我们将提供我们自己的 __cxa_pure_virtual 错误处理函数。如果你不是一个有竞争力的嵌入式软件开发者,你应该在你的自定义处理函数中添加一个无穷无尽的函数。不用担心,只要您遵循该语言的最佳实践,您就永远没有机会调用调用错误处理程序的纯虚函数。

operator newoperator delete 的问题也与底层异常机制有关。为了避免昂贵的异常处理机制,您可以以不引发任何异常的方式重新实现它们。您应该考虑的唯一一件事是在调用operator new 后检查分配是否成功,因为它不会再产生异常。我相信,只要您从事无操作系统的应用程序项目,您就永远不需要致电operator delete

在你自己的代码上应用这个神圣的秘诀后,你会看到可执行文件的大小将回落到原来的状态。

答案对贡献和建议开放。如果你能做到,我将不胜感激

【讨论】:

  • 另一种选择是使用 --disable-libstdcxx-verbose 选项构建 libstdc++ 本身并使用它。异常处理代码不会添加到您的二进制文件中。参考:libstdc++ manual
猜你喜欢
  • 2016-06-21
  • 1970-01-01
  • 1970-01-01
  • 2012-11-27
  • 2022-10-21
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多