回溯中 _start 和 main 之前看到的函数调用
我从同事那里收到了我的程序（在 RHEL 5.3 上运行的 qt 应用程序）的回溯，当我分析它时，我发现了一些我无法解释的东西。如果您查看此回溯，您会注意到 main 和 _start 的跟踪。但在此之前，我们看到我的程序中的 _ZN19datalog_render_area9prepStripEh 和 _ZN12QMutexLockerD1Ev 。我怎样才能看到我的一些函数在 _start 和 main.c 之前被调用？这不是不可能吗？ （请原谅我的回溯的布局）
Funct Addr| Instr. Addr | FunctionSymbol ----------|-------------|----------------------------------------------------------| 0x8060bf2 | 0x8060dc0 | _Z11print_tracev 0x8061386 | 0x806141c | _Z15myMessageOutput9QtMsgTypePKc 0x822b558 | 0x822b598 | _ZN5QListIP13QStandardItemEixEi 0x8229ece | 0x8229f0b | _ZN12vehicleModel14updHeaderModelEP5QListIjE 0x822be7e | 0x822bf64 | _ZN14vehTableWidget19updVehicleTabLayoutEib 0x822c668 | 0x822c8e7 | _ZN14vehTableWidget13setupVehTableEib 0x82845f8 | 0x82846fc | _ZN14vehTableWidget11qt_metacallEN11QMetaObject4CallEiPPv
...程序外部的函数调用
0x8060e86 | 0x80612ce | main _____________________|____________________|address outside of program: 4804252 0x8060a70 | 0x8060a91 | _start _____________________|____________________|address outside of program: 3218418744 0x808df02 | 0x808df13 | _ZN12QMutexLockerD1Ev _____________________|____________________|address outside of program: 3218420336 _____________________|____________________|address outside of program: 152429104 _____________________|____________________|address outside of program: 3218420552 0x8208fa6 | 0x820acd0 | _ZN19datalog_render_area9prepStripEh _____________________|____________________|address outside of program: 3218420336 _____________________|____________________|address outside of program: 3218420500
I received a backtrace of my program (qt app running on RHEL 5.3) from a coworker and as I was analyzing it I found something I could not explain. If you look at this backtrace, you will notice the trace for main and _start. But before that we see _ZN19datalog_render_area9prepStripEh and _ZN12QMutexLockerD1Ev which are in my program. How can I see some of my functions getting called before the _start and main. Isn't that impossible? (pardon the layout of my backtrace)
Funct Addr| Instr. Addr | FunctionSymbol ----------|-------------|----------------------------------------------------------| 0x8060bf2 | 0x8060dc0 | _Z11print_tracev 0x8061386 | 0x806141c | _Z15myMessageOutput9QtMsgTypePKc 0x822b558 | 0x822b598 | _ZN5QListIP13QStandardItemEixEi 0x8229ece | 0x8229f0b | _ZN12vehicleModel14updHeaderModelEP5QListIjE 0x822be7e | 0x822bf64 | _ZN14vehTableWidget19updVehicleTabLayoutEib 0x822c668 | 0x822c8e7 | _ZN14vehTableWidget13setupVehTableEib 0x82845f8 | 0x82846fc | _ZN14vehTableWidget11qt_metacallEN11QMetaObject4CallEiPPv
...function calls outside the program
0x8060e86 | 0x80612ce | main _____________________|____________________|address outside of program: 4804252 0x8060a70 | 0x8060a91 | _start _____________________|____________________|address outside of program: 3218418744 0x808df02 | 0x808df13 | _ZN12QMutexLockerD1Ev _____________________|____________________|address outside of program: 3218420336 _____________________|____________________|address outside of program: 152429104 _____________________|____________________|address outside of program: 3218420552 0x8208fa6 | 0x820acd0 | _ZN19datalog_render_area9prepStripEh _____________________|____________________|address outside of program: 3218420336 _____________________|____________________|address outside of program: 3218420500
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
最有可能的是，您在堆栈上看到了垃圾。为了获得准确的堆栈跟踪，调试器需要帧指针（在 x86 上通常省略以保存寄存器）或调试信息。如果没有这些信息，它会尝试猜测 - 它会扫描堆栈以查找看起来有点像代码地址的指针，并尽力将它们与它们所属的函数相匹配。
正如其他人提到的，静态初始化可能会导致代码在
main之前执行，但该代码在main运行时已返回，因此它们没有必要在真实的堆栈跟踪。我想说，最有可能的是，除了 _start 之外的所有内容都是垃圾数据，可以安全地忽略。Most likely, you're seeing garbage on the stack. In order to get an accurate stack trace, the debugger needs either frame pointers (often omitted on x86 to save a register) or debug information. Without this information, it tries to guess - it scans through the stack for pointers that look sorta-kinda-like code addresses, and does its best to match them to the functions they belong to.
As others have mentioned, static initialization can cause code to be executed before
main, but this code has returned by the pointmainis run, so they have no business being on the true stack trace. I would say that, most likely, everything beyond _start is garbage data and can be safely ignored.这是有可能的。例如，这些函数可以作为某些静态存储持续时间对象的动态初始化的一部分来调用。
玩具示例：
It's possible. For instance these functions could be called as part of the dynamic initialization of some static storage duration object.
Toy example:
看起来您有一个具有静态数据成员的类。该静态数据成员的构造函数正在调用 QMutexLocker。静态数据成员是在调用 main() 之前构造的。
It looks like you have a class that has a static data member. The constructor for that static data member is calling QMutexLocker. Static data members are constructed before main() is called.