Re: Terminate .eh_frame in VDSO with a 4-byte 0

[Paul M. <le...@li...>]

On Sun, Jun 17, 2007 at 07:23:32AM +0900, Kaz Kojima wrote:
> The 2nd one is about VDSO.
> It's assumed that .eh_frame is terminated with 4-byte 0 in shared
> libraries and executable.  It seems to be the case for VDSOs too.
> Without this terminator, I saw failures when unwinding from VDSO,
> though I don't know how other architectures handle this issue.
> For the normal libs, crtendS.o gives this terminator.  We can use
> such terminating objects.  Or we can add a 4-byte 0 with modifying
> the linker script like as the patch below.
> 
At least looking at the i386 implementation, it looks like it's
explicitly padded out on a 4-byte boundary at the end of eh_frame.

So, we can either pad it out in vsyscall-trapa.S directly, or just stick
with the linker script hack. I would prefer to have this padding in the
vsyscall code rather than in the linker script, so it's more consistent
with what the other architectures do.

Others (like ia64) don't have an eh_frame for their linux-gate at all,
interesting.

> BTW, I've found that SH boards set CONFIG_VSYSCALL=y as default.
> Brave enough! :-)
> 
I figured no one would test it if it wasn't default-enabled, and people
would complain very quickly if the signal trampoline suddenly broke. In
the long term I plan on removing the option entirely and just setting it
as def_bool y if MMU. It can be disabled via the kernel command line or
via the sysctl interface at run-time (some folks may want to be rid of
the randomized vdso VMA entirely when debugging).