Closed Febbe closed 11 months ago
Looks like @HazardyKnusperkeks fixed this with https://github.com/ianlancetaylor/libbacktrace/issues/82#issuecomment-1340460448
@Febbe How does that fix make it into this repo?
@Febbe How does that fix make it into this repo?
What do you mean?
Your PR is open, and the commit you pointed to is in another repo. It looks like the master branch of this repo still does not support ASLR on mingw64?
Your PR is open, and the commit you pointed to is in another repo. It looks like the master branch of this repo still does not support ASLR on mingw64?
That's right, it seems that the fix is only applied to GCC, which uses libbacktrace for c++23. If you want to have this fixed, you can checkout my fork or apply the patches yourself.
When you want to see it in this repo, you must wait until Ian lance Taylor has the time to apply the patches himself.
The patch from https://github.com/ianlancetaylor/libbacktrace/pull/110#issuecomment-1715795506 is already in this repo. It's commit afe2967c773eba6b16dfe2ea5e0bb5cd721516a2. Is there another patch that needs to be brought over? Thanks.
Those are missing: [PATCH 2/4] libbacktrace: detect executable path on windows [PATCH 3/4] libbacktrace: work with aslr on windows [PATCH 4/4] libbacktrace: get debug information for loaded dlls
Note, that they partially fix my comment regarding the windows executable path in this PR , except that paths longer than 260 characters are ignored.
Thanks. Those patches have not been committed upstream. I've been waiting for someone to confirm that the modified version that I wrote works.
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610540.html https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611407.html
Can you check that modified patch? Thanks.
I had to modify the patch, because of c1c86fa2f0d9509b99f0d90f240dc71086458af5 and I am not sure, if I ran the tests right, but it looks good except 2 warnings due to unused parameters:
Febbe@DESKTOP-VIRN68C UCRT64 ~/ianlancetaylor/libbacktrace/build
$ ../configure
$ make
$ make test_pecoff.exe
$ ./test_pecoff.exe && (echo successfully) || echo failed
successfully
Tested it also in PS C:\msys64\home\Febbe\ianlancetaylor\libbacktrace\build> C:\msys64\home\Febbe\ianlancetaylor\libbacktrace\build\aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\aaaaaaaaaaaaaaaaaaaaaaaaaaaa\test_pecoff.exe
(259 characters, 260 with \0
)
~To test longer paths, I have to edit the registry and restart my computer, brb...~
For longer paths, it falls back to the other variants, just like expected (fails with could not find executable to open
).
Thanks. Those patches have not been committed upstream. I've been waiting for someone to confirm that the modified version that I wrote works.
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610540.html https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611407.html
Can you check that modified patch? Thanks.
I did not come to that, because frankly the GCC review process is tiresome for me. They are basically working (I'm using the patched GCC since my initial proposal), but for GCC 13 I had to adapt Patch 2.
fixes #103
Instead of generating an empty stacktrace, libbacktrace generates now something like this:
To implement the resolution of addresses with ASLR, it is necessary to look into the Process Environment Block (PEB) of a process. It contains all the required information to map the pc to the functions. To read the PEB, functions from the Windows SDK are required. This is not possible via the POSIX API (:/). The functions defined by would do this for POSIX and ELF, but this is not implemented for PE files in MSYS/Mingw/Cygwin environments. Most of the added code reads the PEB and returns the base addresses.
Somehow it was required to subtract the default base-address, which can be overridden by
/BASE
in the case ASLR is not used. The variable name of that address isimage-base
and it was already read from the PE/COFF.I followed the implementation of the elf files. There, all dynamic libraries were loaded via the dl_iterate_phdr after the main executable file has been parsed. However, for PE on Windows this must be done also for the main file, since it also has a random base address.
Last but not least, there are still some issues with PE/COFF stacktraces: for libraries, no PE/COFF with dwarf has been generated, only the
register_frame_ctor
is shown.#5
was in my case the start address 0xffffffffffffffff, so it probably should not be shown.