seh 64

[Timo Kreuzer]

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

[KJK::Hyperion]

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

[KJK::Hyperion]

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?

[Timo Kreuzer]

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

[KJK::Hyperion]

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

[Timo Kreuzer]

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

[KJK::Hyperion]

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