[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 04.09.19 10:51, Jan Beulich wrote:
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).

Yes, this is working. Will modify the patch.


Juergen

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.