Open thesamesam opened 2 weeks ago
thesamesam
commented
2 weeks ago While this might be a bit of work, I want to say that I do think this is valuable, for two reasons:
kvanhees
commented
2 weeks ago On Sat, Aug 24, 2024 at 06:59:33PM -0700, Sam James wrote:
My plan for the weekend was/is to investigate how much work is needed to port to musl. I was expecting most of the time to be spent on the testsuite, but we fail to build:
cmd/bpf_dump.c: In function 'readBPFFile': cmd/bpf_dump.c:23:19: error: implicit declaration of function 'open64'; did you mean 'openat'? [-Wimplicit-function-declaration] 23 | if ((fd = open64(fn, O_RDONLY)) == -1) { | ^
~| openat from test/triggers/libproc-pldd.c:14:
Oh my, I forgot about the bpf_dump tool that I once wrote to assist in my develoment work on porting DTrace to use BPF. That is quite outdated and not at all userful anymore as far as I can see. We can just get rid of it.
nickalcock
commented
2 weeks ago I was going to laugh this off, but while DTrace does incestuous things with the internals of glibc to do symbol lookups in nonstandard lmids and ask victim ld.so's for their symbol lookup ordering info, it does those to glibcs in other processes (and tries to test them, which obviously would have to disable itself if compiling with musl). We extract some critical glibc internal structure offsets at compile time, which does assume we can compile various generator programs against glibc, but we could always provide some fallback pregenerated output I suppose (assuming that output isn't implicitly GPL, it's only a bunch of offsetof()s).
I can immediately think of no fundamental reason why we can't compile against musl, though under testing mode we turn on things like recursive mutexes which IIRC musl will never implement %but that's an edge case).
The biggest evil thing we do that requires glibc internals in the dtrace process itself is in the replacement for waitfd() in libdtrace/dt_proc.c, where we need thread-directed signals from timer_create() to cover a nasty race:
sev.sigev_notify = SIGEV_SIGNAL | SIGEV_THREAD_ID;
sev.sigev_signo = dtp->dt_proc_signal;
sev._sigev_un._tid = gettid();
if (timer_create(CLOCK_MONOTONIC, &sev, &dpr->dpr_proxy_timer) < 0) {There is no standard way to do this, this uses glibc internals, but obviously Linux can do it (and we don't care at all about portability to non-Linux): does musl have some way to do it? If it doesn't, I don't know any way to implement dtrace -c without said nasty race. See commits c883bd437cfbb8269ebbe6c78171a0d2e08c029c and 234b39beb0e0083381df6bb498491f2904d5d087.
My plan for the weekend was/is to investigate how much work is needed to port to musl. I was expecting most of the time to be spent on the testsuite, but we fail to build:
I'll analyse the failures more, I don't need help at this point (may do later).