使用 LLVM 编译时调试符号有用吗?

发布于 2024-12-01 10:10:04 字数 380 浏览 1 评论 0原文

我正在尝试连接实时崩溃报告服务,例如 airbrakebugsenseTestFlight 的 SDK,但我想知道崩溃报告是否是使用 LLVM 编译器编译 MonoTouch 项目时,崩溃生成的代码很有用。

当您配置 iPhone 版本时,如果您转到“项目设置”>“ iPhone 构建>高级选项卡显示“实验性的,与调试模式不兼容”。这就是为什么我质疑崩溃报告中的堆栈跟踪。

I'm trying to hook up a real-time crash reporting service like airbrake, bugsense or TestFlight's SDK but I'm wondering if the crash reports that are generated from crashes are any good when compiling your MonoTouch project using the LLVM compiler.

When you're configuring an iPhone build if you go to the proj settings > iPhone Build > Advanced tab it says "Experimental, not compatible with debug mode". This is why I'm questioning the stacktrace from the crash reports.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

杯别 2024-12-08 10:10:04

这里有几点需要考虑:

a) 在构建上启用调试

  • 告诉编译器发出调试符号(例如 .mdb 文件),其中包含大量信息(变量名称、范围、行号...);
  • 向您的应用程序添加额外的调试代码(例如,将设备上的应用程序连接到 Mac 上的调试器);
  • 告诉编译器(例如 AOT)禁用某些优化(这会使调试变得更加困难);

这会导致应用程序更大、速度更慢,其中包含大量您不希望人们访问的数据(例如,如果您担心逆向工程)。对于发布来说,这对每个人来说都是一个双赢的局面。

b) 使用LLVM编译器无法在调试模式下工作。这通常不是问题,因为在调试时,您可能希望构建过程尽可能快(而 LLVM 的构建速度较慢)。一个有问题的情况是如果您的错误仅出现在 LLVM 构建上。

c) 托管堆栈跟踪的可用性不需要调试符号。它们是根据 .dll 和 .exe 文件中可用的元数据构建的。但是,当调试符号可用时,堆栈跟踪将包括每个堆栈帧的行号和文件名。

d) 我从未使用过您提到的工具,但我确实相信它们很有用:-) 您可能希望询问有关它们的具体问题(关于 MonoTouch)。否则,我认为值得测试一下细节级别是否不同(以及额外的细节是否对您有任何帮助)。 IMO 我怀疑它会给你带来的不仅仅是运输“调试”版本的实际“成本”。

  • 首先在您的应用程序中创建一个“crash me”功能;
  • 然后比较非 LLVM“发布”和“调试”构建的报告结果;
  • 接下来比较非 LLVM“发布”和 LLVM“发布”版本;

很高兴发布您对上述内容的体验:这里,单触摸邮件列表和/或博客条目:-)

There are several points to consider here:

a) enabling debug on your builds:

  • tells the compilers to emit debugging symbols (e.g. the .mdb files) which includes a lot of information (variables names, scopes, lines numbers...);
  • add extra debugging code to your application (e.g. to connect the application, on the device, to the debugger, on your Mac);
  • tells the compiler (e.g. AOT) to disable some optimizations (that would make debugging harder);

This result in larger, slower applications that contains a lot of data you don't want people to access (e.g. if you fear reverse engineering). For releases it's a no win situation for everyone.

b) using the LLVM compiler won't work with debug mode. It's generally not an issue since, when debugging, you'll likely want the build process to be as fast as possible (and LLVM is slower to build). A problematic case is if your bug shows up only on LLVM builds.

c) The availability of managed stack traces do not requires debug symbols. They are built from the metadata available in your .dll and .exe files. But, when debugging symbols are available, the stack trace will include the line numbers and filenames for each stack frame.

d) I never used the tools you mentioned, but I do believe them to be useful :-) You might wish to ask specific questions about them (wrt MonoTouch). Otherwise I think it's worth testing to see if the level of details differ (and if the extra details are of any help to you). IMO I doubt it will bring you more than the actual 'cost' of shipping 'debug' builds.

  • first create a "crash me" feature in your application;
  • then compare reported results from non-LLVM "release" and "debug" builds;
  • next compare the non-LLVM "release" and LLVM "release" builds;

It be nice to post your experience of the above: here, monotouch mailing-list and/or a blog entry :-)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文