This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] x86: Keep __patchable_function_entries sections with --gc-sections
- From: Fangrui Song <i at maskray dot me>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Sat, 1 Feb 2020 10:21:48 -0800
- Subject: Re: [PATCH] x86: Keep __patchable_function_entries sections with --gc-sections
- References: <20200201162613.2023476-1-hjl.tools@gmail.com> <20200201173429.ep5siwkbhz5osehk@google.com> <CAMe9rOp0cFJLxW1K=av9F1HmS0q-CmmdFcx9LwTQiOddf=417g@mail.gmail.com>
On 2020-02-01, H.J. Lu wrote:
On Sat, Feb 1, 2020 at 9:34 AM Fangrui Song <i@maskray.me> wrote:
On 2020-02-01, H.J. Lu wrote:
>After all text sections have been garbage collected, if a
>__patchable_function_entries section references a section which
>wasn't marked, mark it with SEC_EXCLUDE and return NULL. Otherwise,
>keep it.
>
>Should it be handled in _bfd_elf_gc_mark_extra_sections?
Thanks for paying attention to these feature requests.
I referenced GNU as and ld requests at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492#c2
If we
* implement SHF_LINK_ORDER
I am not sure if overloading (abusing?) SHF_LINK_ORDER is a good idea.
It is an extension, but it is agreed by multiple parties on
https://groups.google.com/d/msg/generic-abi/_CbBM6T6WeM/eGF9A0AnAAAJ ,
including HP-UX and Solaris developers.
* allow multiple sections with the same name ("unique")
This is orthogonal to this. I have a question on assembly syntax:
https://sourceware.org/bugzilla/show_bug.cgi?id=25380#c1
* teach GCC to use SHF_LINK_ORDER and "unique" (see https://gcc.gnu.org/ml/gcc/2020-01/msg00067.html)
An ad-hoc gc marking will be unnecessary.
We need to scan relocations in _patchable_function_entries section for
references to garbage collected sections. We can either check section
name or a SHF_XXX. But I don't know if SHF_LINK_ORDER is a good
approach.
We don't need to if we use multiple __patchable_function_entries
sections. Multiple sections are a must due to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93195#c1 (COMDAT)
A symbol table entry with STB_LOCAL binding that is defined relative
to one of a group's sections, and that is contained in a symbol table
section that is not part of the group, must be discarded if the group
members are discarded. References to this symbol table entry from
outside the group are not allowed.
The __patchable_function_entries creation logic I implemented in clang:
foreach function foo
find the first function label defined in foo's section, name it $associated
($associated can have 2 reasonable values, w/ or w/o -ffunction-sections)
get or create an id for $associated, say, $unique
if foo is in a COMDAT named $comdat
.section __patchable_function_entries,"awo",@progbits,$associated,comdat,$comdat,unique,$unique
else
.section __patchable_function_entries,"awo",@progbits,$associated,unique,$unique
This approach uses feature requests I referenced in *direct* links of
https://gcc.gnu.org/ml/gcc/2020-01/msg00067.html plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492#c2 ,
and addresses all bugs I filed.
SHF_LINK_ORDER has been used in a few sanitizers. Now we know
__patchable_function_entries can benefit from it. In the future, they
may be instances. We really need a general solution.
--
H.J.