HEADS-UP: Planning on deprecating libc_r for 6.0

[Dan Nelson]

In the last episode (Apr 13), Scott Long said:
> Now that we've had working KSE for 2 years, I'm planning to declare
> that libc_r will be deprecated in 6.0 and removed by or before 7.0. 
> That means that libc_r will still be built and installed and usable
> for 6.0 and likely for most of the 6.x lifetime, but its visibility
> will decrease in favor of libpthread and possibly libthr.  Given that
> 7.0 is at least 2 years away, that should give plenty of time for
> migration and testing.  I assume that libc_r will also live on in
> compatibility library archives long after that for those with legacy
> apps.

On a somewhat related note (libpthread/libthr feature parity with
libc_r), is there any way to get truss to be kse/thr aware?  Currently
you can't trace kernel-threaded apps because the thread-switching
syscalls get in the way.  Compare the output of:

truss host www.yahoo.com
LD_LIBMAP=libpthread.so.1=libthr.so.1 truss host www.yahoo.com
LD_LIBMAP=libpthread.so.1=libc_r.so.5 truss host www.yahoo.com

The libc_r one is the only one with useable output.

ports/sysutils/pstack (prints the stacks of a running process) is
another handy tool that's libc_r only.  Is libthread_db something that
can help here and hide the differences between the libs?

-- 
	Dan Nelson
	dnelson at allantgroup.com