Fixed build error with missing _pthread_getname_np symbol reference

It seems extremely late in the release to be doing a malloc update.

I still get error

cd /usr/src; _PARALLEL_SUBDIR_OK=1 time env MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE= BUILD_TOOLS_META=.NOMETA CC="cc -target x86_64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CXX="c++  -target x86_64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"  CPP="cpp -target x86_64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"  AS="as" AR="ar" ELFCTL="elfctl" LD="ld"  LLVM_LINK="" NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size" STRIPBIN="strip"  INSTALL="install -U"  PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin  SYSROOT=/usr/obj/usr/src/amd64.amd64/tmp make  -f Makefile.inc1  BWPHASE=everything  DESTDIR=/usr/obj/usr/src/amd64.amd64/tmp all
(cd /usr/src/lib/csu/tests/dynamic &&  DEPENDFILE=.depend.init_test  NO_SUBDIR=1 make -f /usr/src/lib/csu/tests/dynamic/Makefile _RECURSING_PROGS=t  PROG=init_test )
Building /usr/obj/usr/src/amd64.amd64/lib/csu/tests/dynamic/init_test.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/tests/dynamic/init_test.full
ld: error: undefined reference due to --no-allow-shlib-undefined: _pthread_getname_np
>>> referenced by /usr/obj/usr/src/amd64.amd64/tmp/lib/libc.so.7
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

Updated FREEBSD-diffs

In D41421#943650, @imp wrote:

In D41421#943562, @minsoochoo0122_proton.me wrote:

In D41421#943128, @lwhsu wrote:

Thanks for the work! One thing I would like to mention is that it seems having some issue building or running on 32-bit older CURRENT: https://github.com/jemalloc/jemalloc/pull/2228

I did some test on 32-bit FreeBSD and I found out that when clock_gettime is used on 64bit machine but compiled in 32bit, it sets tv_sec (time_t) as -1. On 32bit FreeBSD, clock_gettime works as expected.

that seems like it's a bug. On powerpc and amrv7 tv_sec should be the same. On i386, tv_sec is only32-bit, but we still have a dozen years left until it's inadequate. Can you finle a bug, if you haven't already, with a way to reproduce this?

In D41421#943562, @minsoochoo0122_proton.me wrote:

In D41421#943128, @lwhsu wrote:

Thanks for the work! One thing I would like to mention is that it seems having some issue building or running on 32-bit older CURRENT: https://github.com/jemalloc/jemalloc/pull/2228

I did some test on 32-bit FreeBSD and I found out that when clock_gettime is used on 64bit machine but compiled in 32bit, it sets tv_sec (time_t) as -1. On 32bit FreeBSD, clock_gettime works as expected.

In D41421#943128, @lwhsu wrote:

Thanks for the work! One thing I would like to mention is that it seems having some issue building or running on 32-bit older CURRENT: https://github.com/jemalloc/jemalloc/pull/2228

In D41421#943128, @lwhsu wrote:

Thanks for the work! One thing I would like to mention is that it seems having some issue building or running on 32-bit older CURRENT: https://github.com/jemalloc/jemalloc/pull/2228

Thanks for the work! One thing I would like to mention is that it seems having some issue building or running on 32-bit older CURRENT: https://github.com/jemalloc/jemalloc/pull/2228

Solved libc build error. However, linking fails with error that _pthread_getname_np is undefined symbol.

Building /usr/obj/usr/src/amd64.amd64/lib/csu/tests/dynamic/init_test.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/tests/dynamic/init_test.full
ld: error: undefined reference due to --no-allow-shlib-undefined: _pthread_getname_np
>>> referenced by /usr/obj/usr/src/amd64.amd64/tmp/lib/libc.so.7
clang: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

When I build new jemalloc, clang generates an error:

jemalloc_prof_sys.c:310:9: error: call to undeclared function 'pthread_getname_np'; ISO C99 and later do not support implicit function declarations [-Werror,-Wimplicit-function-declaration]
        return pthread_getname_np(pthread_self(), buf, limit);
               ^
jemalloc_prof_sys.c:310:9: note: did you mean '_pthread_getname_np'?
/usr/src/include/pthread.h:305:6: note: '_pthread_getname_np' declared here
int             pthread_getname_np(pthread_t, char *, size_t);
                ^
/usr/src/lib/libc/include/namespace.h:141:30: note: expanded from macro 'pthread_getname_np'
#define         pthread_getname_np              _pthread_getname_np
                                                ^
1 error generated.
*** [jemalloc_prof_sys.o] Error code 1

although <pthread.h> is already included. Any ideas?

Rebase.

Seems reasonable, and with some quick grep and find, I didn't find anything else to remove.

New diff file

I reverted all the m_qidx changes, lost a wee bit of perf across all mutex flavors, but numbers still look pretty good.

Updated diff to provide full context via diff -U99999999 ...

Please, when uploading patches to phabricator, do git diff -U99999999, to provide enough context. I will reply to the patch after you re-upload it.

I think releng maintains their own checklist of things to do for a new stable branch, I've tagged them here so they can think about toggling this setting (presumably in src.opts.mk) when creating new stable branches.

Please handle jhb' suggestions, then you can git am the patch to me.

Thanks John, I've updated the patch as requested, including the tools/build/options change (I wasn't aware of that, pretty cool!)

also the procedure for branching a stable needs to include this, but from my grep i don't see anything in src for malloc_production which has the desired treatment

I would perhaps call the option MK_PTHREADS_ASSERTIONS to match MK_LLVM_ASSERTIONS in terms of naming.

LGTM but someone else should also take a look

No need to close it. An additional quirk is fine. I'll commit it today

I'm not sure what the Chromebook id permutations are. I don't have a more general solution for this issue.

In D40405#928098, @jon_thesoo.org wrote:

If not, this can go in as is...

Do I have to do anything else for it to be committed?

If not, this can go in as is...

In D40407#920099, @imp wrote:

So why does this fix things? Otherwise, looks like it's OK

So why does this fix things? Otherwise, looks like it's OK

So.. looks good to me...
It would be awesome if we could automatically detect this quirk... maybe if the probe works turn the rest off? If you are up for trying that...
If not, this can go in as is...

after feedback from @kevans on IRC, I'm abandoning this revision, because it's the wrong way to solve this problem:

• fix case syntax
• use dirname, not basename

The mdoc(7) changes look good to me.

I will try to handle this.

In D34184#804474, @kib wrote:

I still want the answer about use of the kernel addresses for kqueue/eventfd. Generally we try to not introduce new interfaces that directly expose KVA, whatever silly the idea of KASLR is.

I still want the answer about use of the kernel addresses for kqueue/eventfd. Generally we try to not introduce new interfaces that directly expose KVA, whatever silly the idea of KASLR is.

I have accepted this review, but the author points out that it should not be applied since D34576 provides a better implementation.

The patch applied cleanly except for the version update in param.h and the kernel built with this patch and D34323 applied provides the required functionality for ZFS support in lsof-4.85.0.

The patch applied cleanly except for the version update in param.h and the kernel built with this patch and D34184 applied provides the required functionality for ZFS support in lsof-4.85.0.

https://cgit.freebsd.org/ports/commit/?id=3bc8803e5c4a96b60ffe5fa6887e2b73e0df7756

Regardless of the notes I put above, please mail me the git patch with the correct 'Author' metadata.

This is probably irrelevant now that D34756 added a more general way to retrieve advisory lock info.

Is this still relevant?
D34756 added a more general way to retrieve advisory lock info.

FYI D34756
I hope to work on your other patches then.

Thank you for your feedback. New versions of this patch are at:
https://reviews.freebsd.org/D34184
https://reviews.freebsd.org/D34323

Also:

• Add a kf_eventfd_addr field to kf_eventfd and populate it.

In D34090#771984, @damjan.jov_gmail.com wrote:

In D34090#771897, @emaste wrote:

Kernel changes needed for lsof to work using only user mode APIs,

Can you confirm that with the set of changes here and without use of kvm, lsof's full functionality is available?

lsof wants to print the f_ops pointer from struct file, not sure if it's worth adding to struct xfile. It's only used to log debug info for unknown file types.

I strongly recommend not to dig into f_ops. For instance, some file systems overload vnops with something different, while still being normal filesystem. An example is tmpfs.

In D34090#771897, @emaste wrote:

Kernel changes needed for lsof to work using only user mode APIs,

Can you confirm that with the set of changes here and without use of kvm, lsof's full functionality is available?

Kernel changes needed for lsof to work using only user mode APIs,

Please split the patch to per-object. For instance, I think that pipe/socket/kevent changes should be relatively straighforward. While lockf/xvnode do not look so.

Added kf_pipe_buffer_[in/out/size] fields to kf_pipe.