Fedora 38 LLVM vs. Team Fortress 2

Post by gabcoh » Mon, Apr 24, 2023, 9:39 PM UTC

bravetraveler wrote: post #39

gabcoh wrote: post #35

Earlier quoted context omitted.

Can Linux not trivially do the same thing as windows with LD_PRELOAD? If so why is this more of an issue on Linux than Windows? Is it really less a technical challenge and more just a matter of Linux getting less support from upstream developers?

I was thinking/wondering this myself. Not to reinvent the wheel - more toss an idea around, but a 'venv for LD_PRELOAD' sounds like it'd deal with this pretty handily Not... in a way I'd use as a distribution/release maintainer. Probably as an administrator [of my LAN]

Post by stabbles » Mon, Apr 24, 2023, 9:47 PM UTC

gabcoh wrote: post #35

admax88qqq wrote: post #32

Unfortunately this is exactly the type of stuff that makes supporting commercial apps on linux a nightmare. Weird crashes due to weird linking of system libraries. Common distros are very adamant about dynamic linking everything in order to support the use case of "core library has vulnerability, upgrade it in place without rebuilding consuming apps." Along with a desire to avoid "dll hell" and force a single canonic…

Can Linux not trivially do the same thing as windows with LD_PRELOAD? If so why is this more of an issue on Linux than Windows? Is it really less a technical challenge and more just a matter of Linux getting less support from upstream developers?

Post by amluto » Mon, Apr 24, 2023, 9:55 PM UTC

olliej wrote: post #5

amluto wrote: post #3

It should be straightforward to make a little LD_PRELOAD shim to implement the new operator new on top of old overloads and thus restore proper functioning. It would be a gross kludge, though.

I'm not sure that's sound. You can't just redirect an aligned new to the unaligned operator new as you may get unaligned result. It _sounds_ like what is happening is a = ::operator new(some size, some alignment) ... ::operator delete(a); where delete is dropping the align_val_t parameter that would guarantee it hits the same allocator family. There are a variety of ways this can happen, and let's just take it as giv…

Post by amluto » Mon, Apr 24, 2023, 9:56 PM UTC

olliej wrote: post #18

viraptor wrote: post #13

Earlier quoted context omitted.

If you don't mind wasting a bit of time, you could forward size+alignment to the allocator, return the aligned version and keep a record of aligned-to-allocation mapping. (For freeing later) But as the other comment mentioned - it should be a problem for tf2 in the first place since that's not the behaviour they're after.

> If you don't mind wasting a bit of time, you could forward size+alignment to the allocator, return the aligned version and keep a record of aligned-to-allocation mapping. (For freeing later) I'm unsure what you're proposing here - the only methods you know in the replacement allocator are operator new(size_t) and operator delete(void ). The two possible failure paths are: a = ::operator new(some size) ... ::operato…

Post by phkahler » Mon, Apr 24, 2023, 9:58 PM UTC

olliej wrote: post #4

This is a predictable outcome of overriding the global operator new. It remains annoying that this was ever allowed, and is a constant source of pain for c++ standard library implementations.