[PATCH] gas: allow labeling of CFI instructions

Jan Beulich JBeulich@suse.com
Fri Dec 19 16:21:00 GMT 2014

>>> On 19.12.14 at 16:47, <hjl.tools@gmail.com> wrote:
> On Fri, Dec 19, 2014 at 7:35 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 19.12.14 at 15:32, <hjl.tools@gmail.com> wrote:
>>> On Fri, Dec 19, 2014 at 6:26 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> When runtime patching code (like e.g. done by the Linux kernel) there
>>>> may be cases where the set of stack frame alterations differs between
>>>> unpatched and patched code. Consequently the corresponding unwind data
>>>> needs patching too. Locating the right places within an FDE, however,
>>>> is rather cumbersome without a way to insert labels in the resulting
>>>> section. Hence this patch introduces a new directive, .cfi_label. Note
>>>> that with the way CFI data gets emitted currently (at the end of the
>>>> assembly process) this can't support local FB- and dollar-labels.
>>>> gas/
>>>> 2014-12-19  Jan Beulich <jbeulich@suse.com>
>>>>         * gas/dw2gencfi.c (cfi_add_label, dot_cfi_label): New.
>>>>         (cfi_pseudo_table): Add "cfi_label".
>>>>         (output_cfi_insn): Handle CFI_label.
>>>>         (select_cie_for_fde): Als terminate CIE when encountering
>>>>         CFI_label.
>>>>         * dw2gencfi.h (cfi_add_label): Declare.
>>>>         (struct cfi_insn_data): New member "sym_name".
>>>>         (CFI_label): New.
>>>>         * read.c (read_symbol_name): Drop "static".
>>>>         * read.h (read_symbol_name): Declare.
>>> No testcases?
>> Oh, I meant to say a word on the lack thereof: I can't see how to
>> create a meaningful, yet architecture independent test case for
>> this, despite having thought about possibly ways quite a bit. Any
>> suggestions are welcome.
> Can you extract some testcases from x86/x86-64 kernel?

The code to make use of this new directive has yet to be written
(and is unlikely to go upstream due to Linus vetoing any such
changes originating from me). And what help would x86-specific
tests really be? Yes, they may be better than nothing, but
they're in no way helping to avoid breakage (they'd only allow to
maybe notice it earlier after some commit already happened).


More information about the Binutils mailing list