Index | Thread | Search

From:
"Theo de Raadt" <deraadt@openbsd.org>
Subject:
Re: gprof: Profiling a multi-threaded application (revived)
To:
Yuichiro NAITO <naito.yuichiro@gmail.com>
Cc:
mark.kettenis@xs4all.nl, tech@openbsd.org, guenther@openbsd.org, mpi@openbsd.org
Date:
Fri, 13 Jun 2025 07:19:07 -0600

Download raw body.

Thread
> First, we update libc only and bump the libc major. At this point,
> we add just the _gmon_alloc function and export the symbol. No one
> calls the _gmon_alloc function; it prepares the following updates.
> 
> And then wait for the next release that will update xenocara and
> all the packages to link to the new libc.

I don't think splitting into two moments solves the problem.  But
then, I don't actually see the problem Mark is talking about.

If packages need to crank versions to to collect newer DT_NEEDED
references to libpthread, then that's going to be the same story as
new version eference for newer libc, which we've been doing forever
on a regular basis.

Obviously, you and I have compiled this in a base system, and noticed
nothing except that after the major crank of both libraries, the
already installed packages use the older libc/libpthread versions which
does not have the new interface, and it is assumed after the next package
build and update they will use the new versions (but basically not use
this interface at all, because they are not static profiling binaries).

The one detail is that newer libc version has to have storage for
"thread->gmonparam" which is used by libpthread, but it will have
that.

I don't understand the problem.