21

我试图更好地理解符号可见性。GCC Wiki ( http://gcc.gnu.org/wiki/Visibility ) 有一个关于“C++ 异常问题”的部分。根据 GCC Wiki，由于未导出异常，可能会出现运行时错误。没有编译时错误/警告的运行时错误非常危险，所以我试图更好地理解这个问题。我做了一些实验，但我仍然无法重现它。任何想法如何重现问题？

Wiki 中提到了三个库相互使用，所以我做了三个小库。

我运行以下命令：

没有 vtable 的异常类（按预期工作）：

make
./dsouser

带有 vtable 的异常类，但它不导出（甚至不编译）：

make HAS_VIRTUAL=1

异常类导出的 vtable（按预期工作）：

make HAS_VIRTUAL=1 EXCEPTION_VISIBLE=1
./dsouser

生成文件：

CXX=g++-4.7.1
CFLAGS=-ggdb -O0 -fvisibility=hidden
ifdef EXCEPTION_VISIBLE
  CFLAGS+=-DEXCEPTION_VISIBLE
endif
ifdef HAS_VIRTUAL
  CFLAGS+=-DHAS_VIRTUAL
endif
all: dsouser

libmydso.so: mydso.cpp mydso.h
    $(CXX) $(CFLAGS) -fPIC -shared -Wl,-soname,$@ -o $@ $<

libmydso2.so: mydso2.cpp mydso.h mydso2.h libmydso.so
    $(CXX) $(CFLAGS) -L.  -fPIC -shared -Wl,-soname,$@ -o $@ $< -lmydso

libmydso3.so: mydso3.cpp mydso.h mydso2.h mydso3.h libmydso2.so
    $(CXX) $(CFLAGS) -L.  -fPIC -shared -Wl,-soname,$@ -o $@ $< -lmydso -lmydso2

dsouser: dsouser.cpp libmydso3.so
    $(CXX) $< $(CFLAGS) -L. -o $@ -lmydso -lmydso2 -lmydso3

clean:
    rm -f *.so *.o dsouser

.PHONY: all clean

mydso.h：

#ifndef DSO_H_INCLUDED
#define DSO_H_INCLUDED
#include <exception>
#define SYMBOL_VISIBLE __attribute__ ((visibility ("default")))
namespace dso
{
  class
#ifdef EXCEPTION_VISIBLE
    SYMBOL_VISIBLE
#endif
    MyException : public std::exception
  {
  public:
#ifdef HAS_VIRTUAL
    virtual void dump();
#endif
    void SYMBOL_VISIBLE foo();
  };
}
#endif

mydso.cpp：

#include <iostream>
#include "mydso.h"
namespace dso
{

#ifdef HAS_VIRTUAL
void MyException::dump()
{
}
#endif

void MyException::foo()
{
#ifdef HAS_VIRTUAL
  dump();
#endif
}

}

mydso2.h：

#ifndef DSO2_H_INCLUDED
#define DSO2_H_INCLUDED
#define SYMBOL_VISIBLE __attribute__ ((visibility ("default")))
namespace dso2
{
  void SYMBOL_VISIBLE some_func();
}
#endif

mydso2.cpp：

#include <iostream>
#include "mydso.h"
#include "mydso2.h"
namespace dso2
{
  void some_func()
  {
    throw dso::MyException();
  }
}

mydso3.h：

#ifndef DSO3_H_INCLUDED
#define DSO3_H_INCLUDED
#define SYMBOL_VISIBLE __attribute__ ((visibility ("default")))
namespace dso3
{
  void SYMBOL_VISIBLE some_func();
}
#endif

mydso3.cpp：

#include <iostream>

#include "mydso2.h"
#include "mydso3.h"

#include <iostream>

namespace dso3
{

  void some_func()
  {
    try
    {
      dso2::some_func();
    } catch (std::exception e)
    {
      std::cout << "Got exception\n";
    }
  }

}

dsouser.cpp：

#include <iostream>
#include "mydso3.h"
int main()
{
  dso3::some_func();
  return 0;
}

谢谢，丹妮

4

1 回答 1

30

我是 GCC 添加类可见性支持的原始补丁的作者，GCC 克隆的原始方法位于http://www.nedprod.com/programs/gccvisibility.html。感谢 VargaD 亲自给我发电子邮件告诉我这个 SO 问题。

您观察到的行为对最近的 GCC 有效，但并非总是如此。当我最初在 2004 年修补 GCC 时，我向 GCC bugzilla 提交了一个请求，要求 GCC 异常处理运行时通过字符串比较它们的错位符号而不是比较地址来比较抛出的类型在这些字符串中 - 当时被 GCC 维护者拒绝为不可接受的运行时成本，尽管这种行为是 MSVC 所做的，并且尽管异常抛出期间的性能通常不被认为是重要的，因为它们应该是罕见的。因此，我不得不在我的可见性指南中添加一个特定的例外，以说明任何抛出的类型都不能在二进制文件中被隐藏，一次都不能，因为“隐藏”胜过“默认”，因此只需一个隐藏符号声明即可保证覆盖所有情况给定二进制文件中的相同符号。

接下来发生的事情我想我们都没有预料到——KDE 非常公开地接受了我贡献的功能。在极短的时间内，几乎所有使用 GCC 的大型项目都采用了这种方式。突然间，隐藏符号成为常态，而不是例外。

不幸的是，少数人没有正确地应用我的指南来处理异常抛出的类型，并且关于 GCC 中不正确的交叉共享对象异常处理的持续错误报告最终导致 GCC 维护人员放弃并在多年后修补字符串比较用于抛出类型匹配，正如我最初要求的那样。因此，在较新的 GCC 中，情况要好一些。我没有更改我的指南和说明，因为自 v4.0 以来，该方法在每个 GCC 上仍然是最安全的，虽然由于现在使用字符串比较，较新的 GCC 在处理异常抛出方面更可靠，但遵循指南的规则并没有什么坏处那。

这给我们带来了 typeinfo 问题。一个大问题是最佳实践 C++ 要求您始终虚拟继承可抛出类型，因为如果您组合两个异常类型都继承（假设）自 std::exception，则拥有两个等距的 std::exception 基类将导致捕获(std::exception&) 自动调用 terminate() 因为它无法解析要匹配的基类，所以你必须永远只有一个 std::exception 基类，并且相同的原理适用于任何可能的 throwable 组合类型。在任何 C++ 库中都特别需要这种最佳实践，因为您无法知道第三方用户将如何处理您的异常类型。

换句话说，这意味着在最佳实践中所有抛出的异常类型总是伴随着每个基类的连续 RTTI 链，并且异常匹配现在是在内部对正在匹配的类型执行成功的 dynamic_cast<> 的情况， O（基类数量）操作。为了使 dynamic_cast<> 在一系列虚拟继承的类型上工作，你猜对了，你需要每一个此链的默认可见性。如果在执行 catch() 的代码中甚至隐藏了一个，那么整个 caboodle 就会翻倒，你会得到一个 terminate()。如果您重新编写上面的示例代码以虚拟继承并查看会发生什么，我会非常感兴趣 - 您的一条评论说它拒绝链接，这很好。但是假设 DLL A 定义了类型 A，DLL B 将类型 A 子类化为 B，DLL C 将类型 B 子类化为 C，并且程序 D 在抛出类型 C 时尝试捕获类型 A 的异常。程序 D 将提供 A 的类型信息，但在尝试获取 B 和 C 类型的 RTTI 时应该会出错。不过，也许最近的 GCC 也修复了这个问题？我不知道，近年来我的注意力集中在 clang 上，因为这是所有 C++ 编译器的未来。

显然，这是一个混乱，但它是一个特定于 ELF 的混乱 - 这些都不会影响 PE 或 MachO，它们都通过首先不使用进程全局符号表来获得上述所有权利。然而，致力于 C++17 的 WG21 SG2 模块研究组必须有效地实现模块的导出模板才能解决 ODR 违规问题，而 C++17 是我见过的第一个使用 LLVM 编写的提议标准头脑。换句话说，C++17 编译器必须像 clang 一样将复杂的 AST 转储到磁盘上。这意味着 RTTI 可用保证的巨大增加——事实上，这就是我们有 SG7 反思研究组的原因，因为 C++ 模块中的 AST 可以极大地增加可能的自我反思机会。换句话说，

所以，简而言之，现在继续遵循我的原始指南。未来十年，情况有望大大改善。并感谢 Apple 为该解决方案提供资金，由于它的难度很大，所以已经很长时间了。

尼尔

于 2013-01-16T17:19:54.587 回答