有没有办法在程序运行时更改Linux上发布代码中的成员变量？
我编写了一个解决某种优化问题的程序。我一直在以越来越低的阈值运行它，我认为我遇到了某种障碍，因为我的程序无法获得更好的结果。它已经运行了大约 5 天......
但是，我在程序中有一些代码，如果它比阈值好，它会保存其数据。因为我没有兴趣再次运行它 5 天，所以我想在程序运行时执行它，但遗憾的是我没有使用 -g 编译它（我正在使用 gcc）。我想做的是将阈值更改为更高的值。
我确实设法使用 gdb 连接到它，并看到了堆栈帧。我现在位于一个方法内，我想访问“this”指针以更改阈值参数。我尝试检查函数地址周围的值，但没有任何意义...... 我如何找出“this”指向哪里？
谢谢。
I wrote a program which solves some kind of optimization problem. I have been running it with increasingly lower thresholds and I think I hit some kind of barrier since my program can't get better results. It has been running for about 5 days...
However, I have some code in the program which saves its data if it is better than the threshold. Since I have no interest in running it for 5 days again I want to do it while the program is running, but sadly I didn't compile it with -g (I am using gcc). What I am trying to do is change the threshold value to a higher value.
I did manage to connect to it using gdb, and see a stack frame. I am now inside a method, and I want to get access to the "this" pointer in order to change the threshold parameter. I tried examining values around the function's address but nothing makes sense...
How do I find out where "this" points to?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，您不需要重新启动程序来调试它。
您应该使用与最初使用的完全相同相同的源和标记来重建它并添加
-g。这将为您提供一个包含调试信息的可执行文件，但在其他方面（几乎）与原始二进制文件相同。nm a.out和nm a.out.debug的输出应该非常接近（可能存在一些细微的差异，但可能不会影响调试）。现在运行gdb a.out.debug，您应该能够进行源代码级调试，并调整阈值。如果失败，您仍然可以做您想做的事情，但会更困难：您必须在程序集级别执行此操作。您可以运行
a.out.debug（启动一个新任务），并在GDBdisas输出中查看参数如何传递到您的例程，以及如何访问阈值。然后，您可以返回到原始可执行文件，并观察那里发生的基本相同的事情。一旦您知道阈值在内存中的位置，您就可以在 GDB 中调整它。First, you don't need to restart the program in order to debug it.
You should rebuild it using exactly the same sources and flags you used originally and add
-g. This will give you an executable that contains debug info, but otherwise is (almost) identical to the original binary. The output fromnm a.outandnm a.out.debugshould be very close (some minor differences are likely to be present, but will likely not affect debugging). Now rungdb a.out.debug <pid>and you should be able to do source-level debugging, and adjust your threshold.If this fails, you can still do what you want, but it will be harder: you'll have to do that at the assembly level. You can run the
a.out.debug(start a new task), and see in GDBdisasoutput how parameters are passed to your routine, and how the threshold is accessed. You can then go back to your original executable, and observe essentially the same things happening there. Once you know where in memory the threshold is located, you'll be able to adjust it in GDB.