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: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Jan Beulich <JBeulich at suse dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Fri, 19 Dec 2014 07:47:06 -0800
- 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>
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?
--
H.J.