On Fri, Apr 14, 2023 at 8:49 PM Rob Landley <r...@landley.net> wrote:
> On 4/14/23 18:49, enh wrote: > > > i don't like assert(), but **static_assert** is really useful for > things like > > > this where you want to say "this code makes an assumption that you > can test at > > > compile time". > > > > Compile time is the time to care about that sort of thing, yes. > > > > Kinda wonder about portability on weirdness like qnx (or the guy in > email who's > > asking about uclibc-ng). I suspect any such asserts would be a > CFG_DEBUG option > > maybe in portability.c? Hmmm... > > > > they haven't made other complaints about C11, so presumably > static_assert is > > fine too? > > I'm not worried about it erroring, I'm worried about it potentially > triggering > in who knows what linker environment possibly producing mach-o binaries. > i think you've mixed up two different threads here... static_assert is a compile-time check. there's currently a dependency in the checksum code on sizeof(toybox) being < 5k-ish. static_assert can help you tell the compiler to fail at compile time if that's not true. (and nothing ends up in the binary.) alignas, on the other hand, _does_ cause changes to the elf/mach-o files. but apple switched to clang before we did :-) (i also tested just now --- alignas works as expected on macOS.) > > > B) it was only ever coincidentally page size, and huge pages > are a > > thing even on > > > x86. > > > > > > > > > well, huge pages are different from non-4KiB non-huge pages. > > > > There was a lot of talk a while back about getting the kernel to > dynamically use > > them (false starts when I was reading about it), but I don't follow > lwn.net > > <http://lwn.net> or > > lkml nearly as closely in 2023 as I did in 2018. It just got too > unpleasant even > > to check over the weekly web archive... > > > > _transparent_ huge pages is yet another different thing :-) > > I am in favor of not having to care, but they did seem to be having a hard > time > with it. > > > Hmmm... Does it actually help to page align them, do you think? Not > sure how to > > benchmark that... > > > > (i was half expecting it to be page aligned for free, as the > > joint-second-largest OBJECT in toybox, but readelf says it isn't, and > neither is > > `this`.) > > > > i don't have good benchmarks either, or i'd have given you data. the > build team > > does keep track of where all the time goes in builds, but (other than > that > > pathological case we had in sed) toybox is unlikely to make their hit > list. > > Yeah, but a zillion little ones add up. Not sure _what_ helped in your > earlier > thingy, and am now curious... > > (And I have NO idea what state I've gotten thunderbird into where the > cursor > blinks once an then vanishes until I move it again. And on more than one > occasion when I hit enter has inserted a line BELOW the last place typing > happened...) > > > (i think for ps, the interesting question is "why does toybox top take > 10% > > cpu?". and although i don't know the answer to that, i don't think that's > > toybuf's fault :-) ) > > I think last time I looked at it I was squinting at the unicode fontmetrics > stuff, but I agree it's waaaaay too expensive. On the todo list but nobody > else > had piped up saying it was blocking them... > > > Oh, hang on: > > > > if (bytes<0 || bytes>(1<<30)) len = (1<<30); > > // glibc added this constant in git at the end of 2017, > shipped 2018-02. > > // Android's had the constant for years, but you'll get SIGSYS > if you use > > // this system call before Android U (2023's release). > > #if defined(__NR_copy_file_range) && !defined(__ANDROID__) > > len = syscall(__NR_copy_file_range, in, 0, out, 0, len, 0); > > #else > > > > That might be worth looking into... > > > > well, the _build_ performance is all on the host. (though until we > switch from > > host glibc to host musl, we probably don't have __NR_copy_file_range > defined > > anyway because of our ancient glibc.) > > Given my recent migration from slack to discord because debian oldstale > won't > update, I can't throw stones... > > > as for the device, we're caught between caring about the current OS > version and > > wanting the static binary to be able to run on old OS versions. we can > trivially > > remove this, but it will break any calling code for pre-U (which is > literally > > "everything currently in anyone's hands"). right now we don't have any > known > > users of the _device_ toybox static prebuilt, but changing this would > likely > > preclude that. > > Sigh. I tried to make it gracefully fall back, and you guys are sending > kill > signals to anything that uses a system call you don't recognize. > like i say every time you complain: because the alternative was worse. we started off just failing the syscalls, but *way* too much code doesn't check, or has untested error paths that don't actually work, or has error paths that do "work" but just hide the failure and make it impossible to debug. if you're trying to do this for a single project, that would be an option. for an entire operating system, not so much. > Need a posix container... > > > if we want to go this route, we'll probably have to go with something > like a > > signal handler for SIGSYS and a boolean. or a weak declaration of the > > copy_file_range() *function*? no, because that's useless for the static > linking > > we're concerned about. > > > > oh, wait... we should just be able to > use android_get_device_api_level()... > > > > i think something like this should work? > > Sigh, lemme finish and check in the fs_type_name() redo. (So many dirty > files in > my tree. Closing tabs...) > well, i should try to test this first... :-) if nothing else, it occurred to me since sending it that we shouldn't check the system property on _every_ call, and should cache that. > Rob >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
