Hi,
I have recently been working on getting SEH into the x64 port. This covers several parts. One of them is compiler support. On x64 SEH is table based rather than code based, that means it needs tables of unwind data. These can be generated from DWARF unwind info - which gcc generates - and that's what I'm working on. The x64 version of rsym shall parse the DWARF unwind data and convert it into Windows compatible unwind data.
Now there is a problem. While older versions of mingw64 used the ".debug_frame" section, the newer versions use the ".eh_frame" section. That is good and bad at the same time. What does that mean? What's the difference? The .eh_frame section isn't part of the DWARF 2 or 3 specification, it's a GNU extension / part of the LSB-Core specification. Documentation was hard to find, but google is your friend and it seems there's only one major difference to the debug_frame section and that is relative addressing rather than absolute. This is actually very good and saves the day for all modules that live in kernel space, because the addresses are only 32 bits.
There is still a problem left. While the .debug_frame section is by default put into the output executable as a seperate section, the .eh_frame section isn't. The default linker script puts it into the ".rdata" section. But there it's kinda lost and I don't want to keep it anyway.
With ntoskrnl there's no problem as it uses it's own linker script anyway. I can change it, so the .eh_frame section is put at the end of the executable. But how do I do this for the other modules? Do i need to provide a new default linkerscript for all other modules? Can I "fix" this behavior in RosBE64 (the files in lib/ldscripts seem to be unused)? Or does anyone know a command line option to change this default behavior?
Regards, Timo
Timo Kreuzer wrote:
I have recently been working on getting SEH into the x64 port. This covers several parts. One of them is compiler support.
Need a hand porting over PSEH? Shouldn't take long and we would help the other ports, too
As for your question: this should be done in pefixup, not rsym, because pefixup is part of the linking phase (and this is something that should be done by the linker), and because doing it in the rsym phase would invalidate the PE checksum calculated in the linking phase. And I'm personally OK with a RosBE linker script
Timo Kreuzer wrote:
I have recently been working on getting SEH into the x64 port. This covers several parts. One of them is compiler support.
What is your plan to make the C front-end of GCC generate the equivalent of SCOPE_TABLE data? And will it have source-level compatibility with PSEH?
KJK::Hyperion schrieb:
What is your plan to make the C front-end of GCC generate the equivalent of SCOPE_TABLE data? And will it have source-level compatibility with PSEH?
Ok, I'm going to explain, because you asked so nice.
#define _SEH_emit_begintry() \ asm volatile (".cfi_escape 0x1c");
This will emit a user defined cfi code in the .eh_frame section. Current offset from function start can be parsed. The data will be parsed together with gcc generated unwind info and converted into RUNTIME_FUNCTION, UNWIND_INFO, UNWIND_CODEs and C_SCOPE_TABLE.
And of cause PSEH source level compatability is planned. Although I might go for msvc source compatability and the create a common wrapper if that works.
Regards, Timo
Timo Kreuzer wrote:
Ok, I'm going to explain, because you asked so nice.
I'm not convinced this can work, and delimiting scopes is only half the battle. How will you generate landing pads? or __finally blocks that are safe to call from RtlUnwind? I think I'll work on a PSEH port on my own
KJK::Hyperion schrieb:
I'm not convinced this can work, and delimiting scopes is only half the battle. How will you generate landing pads? or __finally blocks that are safe to call from RtlUnwind?
This just shows your lack of imagination. For example nested functions would do the trick. They also make sure all variables are made volatile as needed like on msvc. And it produces no overhead if done right. No, nested function *do not* put code on the stack on x64! Oh, I can already hear you whining... oh noes that doesn't conform to C89 standards, it's not portable, lalala And..? Who cares? PSEH is a fucking compiler hack, 'cause gcc doesn't support it natively. Any other compiler that can compile reactos and has no native SEH? No? Ok, so what?
Also being compatible with Windows unwind mechanisms is not just fancy or nice to have. It's needed for 3rd party software/driver compatability.
I think I'll work on a PSEH port on my own
So you want to port SEH from x86? Using sjlj? Cool, dude. Now YOU explain me how you implement a longjmp on x64 without unwinding tables? Doh!
Timo
Timo Kreuzer wrote:
I'm not convinced this can work, and delimiting scopes is only half the battle. How will you generate landing pads? or __finally blocks that are safe to call from RtlUnwind?
This just shows your lack of imagination.
I don't know what, exactly, this... thing is supposed to show about you
So you want to port SEH from x86?
That's right, because apparently you are OK with using features that are only available on MinGW64
-
KJK::Hyperion -
Timo Kreuzer