Open McCzarny opened 2 months ago
If not, is it worth to implement it? I could try to provide the implementation.
Yes, please give it a try
@apolukhin So far the code change needed to make it work on unix is quite simple but I have some difficulties with deciding how to provide a way to enable the new behavior. I will appreciate any help here.
The thing is that it can work with every mode like _BASIC
, _ADDR2LINE
, _BACKTRACE
, so I think that there is no point with creating a new library variant. The easiest option would be to define a new macro flag, but it would require a rebuild to change the way of address printing for projects that links to boost_stacktrace_*
. Alternatively I could add a new type, which will require more code. What do you think?
https://github.com/McCzarny/stacktrace/commit/ec6066f3444b9e99f42194b2ba44164d0516dfdb
Hello, I was trying to use the library to log backtraces so they could be later decoded using the binary. I've noticed that when Address Space Layout Randomization is enabled, I'm getting different address on each run:
It seems that I can still decode the addresses if I get
/proc/self/maps
and subtract the base address from the generated stacktrace. I've noticed that there is a similar logic whenaddr2line
flavor is enabled.I'm aware that the work on the libarary may be limited because of C++23, but still there is a lot projects where it's easier to use a newer version of boost than upgrade a compiler.