i have seen true evil.
-
i *will* have librewolf 149 compiling, TONIGHT, on openbsd -CURRENT
if building with llvm 19 still dosen't work, i'm going to gut mozilla's allocator myself, fixing all the declarations by hand.
using the system allocator directly (no intercept functions) is possible using --disable-jemalloc in ./configure, when building mozilla code. but that means using openbsd's... slow allocator, for every allocation. and that would make the javascript engine slow as molasses.
mozilla firefox is a sin.
here's a thought: maybe *DON'T* redeclare kernel functions in your codebase? if you're having to write your own allocator, then you are hacking around a much deeper problem. but this is mozilla. anything is possible.
-
here's a thought: maybe *DON'T* redeclare kernel functions in your codebase? if you're having to write your own allocator, then you are hacking around a much deeper problem. but this is mozilla. anything is possible.
@libreleah I didn't look deeply into librewolf, but firefox 149.0.2 hums along nicely on -current here, why not base your work on the existing port?
-
@libreleah I didn't look deeply into librewolf, but firefox 149.0.2 hums along nicely on -current here, why not base your work on the existing port?
@vlkrs yeah, no idea why firefox builds on current. (though i didn't test-build that)
have a look here: https://codeberg.org/vimuser/librewolf-openbsd-port
i removed use of www/mozilla and put everything in one place. standalone port.
builds fine with llvm 19 on openbsd 7.8, when you use my stable-7.8 branch (uses librewolf 143)
149 (master branch on my port repo) needs some work. i'm rebuilding with
MODCLANG_VERSION = 19
hopefully that'll fix it for now. and either i, or upstream, will fix mozilla's allocator later.
-
@vlkrs yeah, no idea why firefox builds on current. (though i didn't test-build that)
have a look here: https://codeberg.org/vimuser/librewolf-openbsd-port
i removed use of www/mozilla and put everything in one place. standalone port.
builds fine with llvm 19 on openbsd 7.8, when you use my stable-7.8 branch (uses librewolf 143)
149 (master branch on my port repo) needs some work. i'm rebuilding with
MODCLANG_VERSION = 19
hopefully that'll fix it for now. and either i, or upstream, will fix mozilla's allocator later.
@libreleah Well, I guess I should have looked at your librewolf WIP before commenting
-
here's a thought: maybe *DON'T* redeclare kernel functions in your codebase? if you're having to write your own allocator, then you are hacking around a much deeper problem. but this is mozilla. anything is possible.
There are some interesting edge cases where redefining malloc etc. is useful. Imagine a safety process that has specific requirements like near-constant time, no chance of a failure to allocate, etc.
But I wouldn't say a browser falls into that category ...
-
There are some interesting edge cases where redefining malloc etc. is useful. Imagine a safety process that has specific requirements like near-constant time, no chance of a failure to allocate, etc.
But I wouldn't say a browser falls into that category ...
@TheLancashireman i mean, i wrap malloc in my programs too (mostly to check nulls and such - and i wrap free and make it set a pointer to null after freeing - and my malloc wrapper will err if being given a pointer that isn't null).
but directly redefining functions, yeah, that's evil.
-
here's a thought: maybe *DON'T* redeclare kernel functions in your codebase? if you're having to write your own allocator, then you are hacking around a much deeper problem. but this is mozilla. anything is possible.
@libreleah
Aaaaaaaaaaa -
here's a thought: maybe *DON'T* redeclare kernel functions in your codebase? if you're having to write your own allocator, then you are hacking around a much deeper problem. but this is mozilla. anything is possible.
fuck u mozilla
--- memory/build/mozjemalloc.cpp.orig
+++ memory/build/mozjemalloc.cpp
@@ -5257,7 +5257,7 @@ static void replace_malloc_init_funcs(malloc_table_t* table) {
#endif
#define NOTHROW_MALLOC_DECL(...) \
- MOZ_MEMORY_API MACRO_CALL(GENERIC_MALLOC_DECL, (noexcept(true), __VA_ARGS__))
+ MOZ_MEMORY_API MACRO_CALL(GENERIC_MALLOC_DECL, (, __VA_ARGS__))u will not defeat me mozilla
-
here's a thought: maybe *DON'T* redeclare kernel functions in your codebase? if you're having to write your own allocator, then you are hacking around a much deeper problem. but this is mozilla. anything is possible.
@libreleah malloc isn't a kernel function, it's part of libc -
R relay@relay.infosec.exchange shared this topicR relay@relay.an.exchange shared this topic
-
@libreleah malloc isn't a kernel function, it's part of libc
@noisytoot how asinine. yes, technically you are correct, but what, pray tell, implements said allocator that malloc returns pointers from?
-
@noisytoot how asinine. yes, technically you are correct, but what, pray tell, implements said allocator that malloc returns pointers from?
@libreleah it's using syscalls implemented by the kernel (mmap and/or brk probably), but those aren't what firefox is reimplementing
whatever firefox is doing does seem to break LD_PRELOADing another allocator, which is annoying. when I tried LD_PRELOADing mimalloc globally on alpine it broke audio/video playback
