Re: gas: Question about .cfi_startproc and nested labels

["Jan Beulich" <JBeulich at suse dot com>]

>>> On 17.11.14 at 13:45, <martin.galvan@tallertechnologies.com> wrote:
> On Mon, Nov 17, 2014 at 6:58 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 17.11.14 at 06:09, <martin.galvan@tallertechnologies.com> wrote:
>>> Hi there! I'm trying to add some CFI directives to an existing ARM
>>> code, and I noticed sometimes we have stuff like this:
>>>
>>> some_label:
>>> ...
>>>
>>> some_other_label:
>>> ...
>>>
>>> END
>>>
>>> where "END" is a macro that expands to the appropriate epilogue/return
>>> instructions. If we want to mark those labels as functions, I know
>>> .cfi_endproc should be placed right after the END macro, but what
>>> about .cfi_startproc? I'm thinking of doing something like:
>>>
>>> some_label:
>>> .cfi_startproc
>>> ...
>>>
>>> some_other_label:
>>> .cfi_startproc
>>> ...
>>>
>>> END
>>> .cfi_endproc
>>>
>>> However, I'm not sure if that would be right. Will gas realize
>>> some_label and some_other_label are meant to be different functions?
>>
>> No - these two directives have to strictly alternate. I.e. you'd need
>> another .cfi_endproc right before the second label, or drop the
>> .cfi_startproc right after it. Note that to the unwinder it doesn't
>> really matter whether some internal label of a function is externally
>> callable - all it cares about is that the unwinder state is correct at
>> that (as well as any other) point.
> 
> Thanks a lot for your answer! One more question: what happens if I
> call .cfi_restore_state without having called .cfi_remember_state
> first? I've seen a couple of places where people seem to be doing
> that, but I'm not sure of what the results would be.

I'd expect gas to not accept this, but even if it does it'll produce
data the unwinder can't use - what state should it restore when
none was saved?

Jan