Extending nptl's libthread_db.so interfaces for locking

A question that came up from past and present customers considering
Linux. I'm not 

sure that this is the proper forum to post this, although there is a lot
of details that will 

have to be worked out with folks who are focusing on the nptl
internals/implementation.

Please feel free to direct me to others who are doing work in this area.

 

Is there a plan to provide hooks to enable user mode lock
performance/tracing/debug?

This would include:

- Lock performance, similar to what the lockmeter project provides but
for a user mode 

  threaded application

- Lock debugging, for example to extend gdb with the ability to view a
lock objects 

  state and manipulate it. Event breakpoint on lock taken, or on lock
unavailable. Display 

  the locks that a thread holds.

- Tracing tools based on locks.

 

In general the tools would likely be outside of the charter of this
project. But to enable a 

robust set of tools to do all of these things, make extensions to the
libthread_db.so library

that lock information could be gotten and set from an attached threaded
process, like what

is done for thread states and events now in libthread_db.so for gdb.
This would involve 

adding hooks in nptl and libthread_db.so to add interfaces to do this.
Gdb and other tools

could then use the library to get/set the lock data and generate events
for locks.

 

The APIs to do this in libthread_db.so are not new and are in the public
domain already.

>From a cursory review it looks like /usr/include/libpthread_db.h is
already available in RH 9,

although it's not clear that it's supported as an interface (no man
pages). To add in new 

APIs that follow current practice should not be that difficult.
Designing them where there 

would be minimal/no performance impact on the locking interfaces in nptl
as a result of the

hooks needed to implement the new libthread_db APIs would be a must.

 

This should enable what we have with gdb and libthread_db.so, a mostly
architecture neutral

way to get to the internals of a threaded application. Extending this
for lock objects would 

enable some existing tools for Linux that we are currently lacking.  

 

So, at this point, would there be interest in doing something like this?
Actually, are there

efforts already underway to do this (likely)? Or, are there reasons that
this has not occurred

already? It seems that early on getting NPTL solid was key, that is done
now and making 

changes like this can be considered. Are there other tools projects
underway already?

 

Thanks in advance.

 

Regards,

Dave Howell   

 

 

These are my opinions and not official opinions of Intel Corp.

 

David Howell

Intel Corporation

Telco Server Development

Server Products Division

Voice: (803) 216-2359  Fax: (803) 216-2178

 

Intel Corporation

Columbia Design Center, CBA-1

100 Center Point Circle, Suite 210

Columbia, SC 29210

 

[email protected]