https://sourceware.org/bugzilla/show_bug.cgi?id=33288
Bug ID: 33288
Summary: windows: abnormal program execution after using
partial link and c++ exceptions
Product: binutils
Version: 2.43
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: jean.guyomarch at gmail dot com
Target Milestone: ---
Created attachment 16256
--> https://sourceware.org/bugzilla/attachment.cgi?id=16256&action=edit
minimal work example, plus objdump ouputs
I am trying to compile a minimal working example that involves two trivial C++
sources, with no explicit use to any standard libraries.
There is a try/catch expression in one of these files. The try block throws an
exception that is expected to be caught within the same function.
The program behaves normally when using a "classic" compilation model, but
behaves strangely (I would say it has an undefined behavior) when partial
linking is involved with mingw-w64. I could not reproduce this issue on Linux
with distribution-provided compilers.
I have been using the mingw-w64 toolchain
x86_64-1420-posix-seh-msvcrt-rt_v12-rev0, but older versions resulted in a
similar problem. As per its name, it compiles 64-bit executable code, with the
POSIX thread model, SEH, and msvcrt. It includes g++ 14.2.0 and ld 2.43. I
experienced the same issue with older mingw-w64 compilers.
Below is the compilation workflow that provides a "good" result:
```
g++ s1.cpp -c -o s1.o
g++ s2.cpp -c -o s2.o
g++ -o program.exe s1.o s2.o
Below is the compilation workflow that generates a working executable with an
unexpected behavior:
```
g++ s1.cpp -c -o s1.o
g++ s2.cpp -c -o s2.o
g++ -r -o merged.o s1.o s2.o
g++ -o program2.exe merged.o
```
program.exe completes without error, whereas program2.exe terminates with an
error code (abnormal termination).
The only substantial difference I could find between these two PE binaries
resides in the .pdata section. I've attached the result of objdump -D of the
two binaries. Here is what I've noticed:
* At address 140005078, the pdata entry rightfully describes the main function
for the correct executable. The start and end addresses both look good.
* The same entry in the incorrect executable describes code that starts at the
beginning of function recurse and ends somewhere after the end of the main
function. Code with more instructions may yield to even more bizarre addresses,
that may end in the middle of a function.
To me, the pdata section generated when partial linking is involved is
incorrect, and this causes undefined behavior when the content of the pdata are
used (e.g. when an exception occurs).
If you need to reproduce this issue, or if you want the full details, please
find attached a compressed archive that contains:
* s1.cpp and s2.cpp, the minimal sources mentioned above.
* output-good.S, which is the result of objdump.exe -D of progam.exe (with a
nominal execution).
* output-bad.S, which is the result of objdump.exe -D of progam2.exe (with an
abnormal execution).
I have opened an issue on mingw-w64
(https://github.com/mingw-w64/mingw-w64/issues/114), but it seem it may be
related to GNU ld more specifically.
Is there any action that can help with this issue?
Thanks.
--
You are receiving this mail because:
You are on the CC list for the bug.
