Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

Jiri Slaby
2017-03-22T07:39:44Z

On 03/22/2017, 08:25 AM, Ingo Molnar wrote:
>
> * Pavel Machek <pavel@ucw.cz> wrote:
>
>> Hi!
>>
>>> -ENTRY(saved_rbp) .quad 0
>>> -ENTRY(saved_rsi) .quad 0
>>> -ENTRY(saved_rdi) .quad 0
>>> -ENTRY(saved_rbx) .quad 0
>>> +SYM_DATA_START(saved_rbp) .quad 0
>>> +SYM_DATA_START(saved_rsi) .quad 0
>>> +SYM_DATA_START(saved_rdi) .quad 0
>>> +SYM_DATA_START(saved_rbx) .quad 0
>>
>> Does it make sense to call it SYM_DATA_*START* when there's no
>> corresponding end?
>
> That looks like a bug - I think we should strive for them to always be in pairs.
>
> Jiri, Josh, could objtool help here perhaps, to detect 'non-terminated'
> SYM_*_START() uses? This could be done by emitting debug data into a special
> section and then analyzing that section for unpaired entries. The section can be
> discarded in the final link, it won't show up in the kernel image.

It should be easier than that. No introduction of other info needed --
every global symbol without a ".type" or ".size" (i.e. SYM_*_END) should
be a bug now.

> We don't ever nest symbols, right?

AFAI could see so far, correct.

>> Plus... it looks like saved_rsi (and friends) are only used inside
>> wakeup_64.S. Could we just delete the "ENTRY" annotations?
>
> That appears to make sense as well.

+1, will fix this.

thanks,
--
js
suse labs