Re: How to stop --gc-sections nukeing all sections?

[greyham at research dot canon dot com dot au (Graham Stoney)]

> From: greyham@research.canon.com.au (Graham Stoney)
> 
> The kernel uses a nasty ha^H^H^H^H^H^H^H^Hneat trick to trap bad user space
> accesses. This relies on incrementally building up two tables containing
> references to instructions which attempt user space accesses, in sections
> named .fixup and __ex_table sections. These tables must be ordered in the same
> order as the code they refer to, because a binary search is done on the
> __ex_table and this search requires that the entries are in ascending order.

Ian Lance Taylor writes:
> Geeze, can't we do this in a way which doesn't rely on undocumented
> linker features?  C++ exception handling manages to solve a similar
> problem without a similar drawback.

That would be excellent. The current magic is done with a macro like:

#define __put_user_asm(x, addr, err, op)                        \
        __asm__ __volatile__(                                   \
                "1:     "op" %1,0(%2)\n"                        \
                "2:\n"                                          \
                ".section .fixup,\"ax\"\n"                      \
                "3:     li %0,%3\n"                             \
                "       b 2b\n"                                 \
                ".previous\n"                                   \
                ".section __ex_table,\"a\"\n"                   \
                "       .align 2\n"                             \
                "       .long 1b,3b\n"                          \
                ".previous\n"                                   \
                : "=r"(err)                                     \
                : "r"(x), "b"(addr), "i"(-EFAULT), "0"(err))

The assumption it makes is that the __ex_table entries end up in the same
order as the instruction at label 1:. Any chance you could point me to a
description of how the support for C++ exception handling works?

Thanks,
Graham