This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] gas: allow labeling of CFI instructions
- From: "Jan Beulich" <JBeulich at suse dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: "Binutils" <binutils at sourceware dot org>
- Date: Fri, 19 Dec 2014 16:21:18 +0000
- Subject: Re: [PATCH] gas: allow labeling of CFI instructions
- Authentication-results: sourceware.org; auth=none
- References: <549443A90200007800051089 at mail dot emea dot novell dot com> <CAMe9rOqmE9NnzzGVLxOO=pJ2KJxKUpR5Ze07QVWGWxqcEjGvsA at mail dot gmail dot com> <549453E70200007800051111 at mail dot emea dot novell dot com> <CAMe9rOoWV-KL32gaQEwNH7j0wAhegu=7pN1P8TGaxZuyda77fw at mail dot gmail dot com>
>>> 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).
Jan