Needs porting to musl #87
Comments
|
While this might be a bit of work, I want to say that I do think this is valuable, for two reasons:
|
|
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.
|
|
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: 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 c883bd4 and 234b39b. |
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).
The text was updated successfully, but these errors were encountered: