Re: [Xen-devel] [PATCH v3 5/5] xen: modify several static locks to unique names

[Jan Beulich <jbeulich@xxxxxxxx>]

On 04.09.2019 10:47, Juergen Gross wrote:
> On 04.09.19 10:40, Jan Beulich wrote:
>> On 04.09.2019 10:25, Juergen Gross wrote:
>>> On 03.09.19 17:09, Jan Beulich wrote:
>>>> On 03.09.2019 17:03, Juergen Gross wrote:
>>>>> On 03.09.19 16:53, Jan Beulich wrote:
>>>>>> On 29.08.2019 12:18, Juergen Gross wrote:
>>>>>>> In order to have unique names when doing lock profiling several local
>>>>>>> locks "lock" need to be renamed.
>>>>>>
>>>>>> But these are all named simply "lock" for a good reason, including
>>>>>> because they're all function scope symbols (and typically the
>>>>>> functions are all sufficiently short). The issue stems from the
>>>>>> dual use of "name" in
>>>>>>
>>>>>> #define _LOCK_PROFILE(name) { 0, #name, &name, 0, 0, 0, 0, 0 }
>>>>>>
>>>>>> so I'd rather suggest making this a derivation of a new
>>>>>>
>>>>>> #define _LOCK_PROFILE_NAME(lock, name) { 0, #name, &lock, 0, 0, 0, 0, 0 }
>>>>>>
>>>>>> if there's no other (transparent) way of disambiguating the names.
>>>>>
>>>>> This will require to use a different DEFINE_SPINLOCK() variant, so e.g.
>>>>> DEFINE_SPINLOCK_LOCAL(), which will then include the needed "static" and
>>>>> add "@<func>" to the lock profiling name. Is this okay?
>>>>
>>>> To be frank - not really. I dislike both, and would hence prefer to
>>>> stick to what there is currently, until someone invents a transparent
>>>> way to disambiguate these. I'm sorry for being unhelpful here.
>>>
>>> I think I have found a way: I could add __FILE__ and __LINE__ data to
>>> struct lock_profile. In lock_prof_init() I could look for non-unique
>>> lock names and mark those to be printed with the __FILE__ and __LINE__
>>> data added to the names.
>>>
>>> Would you be fine with this approach?
>>
>> I would be, but I'm afraid Andrew won't (as with any new uses of __LINE__).
>> I wonder if __func__ or __FUNCTION__ could be used - the main question is
>> how they behave when used outside of a function. If either would be NULL
>> (rather than triggering a diagnostic), it might be usable here. Of course
>> this would be fragile if just based on observed (rather than documented)
>> behavior.
> 
> With gcc 7.4.1 it fails:
> 
> /home/gross/xen/xen/include/xen/spinlock.h:80:41: error: ‘__func__’ is 
> not defined outside of function scope [-Werror]
>   #define _LOCK_PROFILE(name) { 0, #name, __func__, &name, 0, 0, 0, 0, 0 }

Right, as I was afraid of. But __PRETTY_FUNCTION__ looks to be suitable
(as per the gcc doc, and as per there being clear indications that clang
also supports this).

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel