Recent activity

Re: Speculations on arenas and custom strings in C++ a day ago

From Christopher Wellons to ~skeeto/public-inbox

Thanks for the information, Jonathan. This was very helpful! The three 
"problematic for multiple reasons" items in your article are spot on, 
capturing my own feelings.

> simply `static_cast<T&&>(arg)` (or `(T&&)arg` ...)

Ha, it's so simple. I tried throwing everything at it I might care about, 
and it worked. Your article gives me confidence it's correct, too. Part of 
my confusion was stuff like this Stack Overflow discussion, about why the 
static cast isn't quite right, the need for remove_reference, etc.

So I gave up on trying to work it out myself. I should have just tried it.

Re: Arena allocator tips and tricks a month ago

From Christopher Wellons to ~skeeto/public-inbox

Thanks for the followup!

> It's difficult (for me, at least) to read code where assignments are 
> being hidden behind macros.

Same for me, so I'd probably dislike it for the same reason. Though at 
least it's not a worse case: when variable declarations are hidden inside 

Re: Useful macro for C arrays a month ago

From Christopher Wellons to ~skeeto/public-inbox

Nice macros, Julien, and in the same spirit as my dynamic array macro. I 
like that even the sizes are type-generic, at least for signed sizes. It 
also illustrates the usefulness of signed sizes: No overflow subtracting 
from the countof result, i.e. n > countof(dst).

Re: Practical libc-free threading on Linux 2 months ago

From Christopher Wellons to ~skeeto/public-inbox

> [...] so then that would require me to implement a "good" SPMC-queue 
> with all the scheduling headaches [...]

With good I/O queues the kernel does most of that work for you: completion 
ports on Windows, io_uring on Linux, on kqueue on BSD. Block all threads 
on the queue and let the kernel schedule them. Linux epoll was infamously 
bad at exactly this, addressed with later hacks (i.e. EPOLLONESHOT), but 
you don't need it anymore. You'll need one platform layer per I/O queue 
API. Only on the legacy interfaces (i.e. select, poll), if you support 
them at all, do you need to implement your own SPMC.

The HTTP application is the rest, all platform-agnostic: parsing HTTP 
headers, managing session state, etc. The platform layer's job is just to 
read some bytes, pass them into the application on some thread, and write

Re: Practical libc-free threading on Linux 2 months ago

From Christopher Wellons to ~skeeto/public-inbox

ASan generally won't work with libc-free anything, so that error is not 
surprising. It expects specific, mostly undocumented behaviors from the 
runtime, with memory mapped a certain way for shadow bytes. It needs to be 
informed about stacks, and so needs to hook into thread creation. Getting 
ASan to work on top of a custom, low-level thread library is essentially 
the same as porting it to a new platform. It's a similar story for glibc 
alternatives like musl, which even still has limited ASan support.

Same goes for TSan, which not only needs to be informed about all threads, 
but also needs to understand all synchronization primitives. That happens 
automatically with atomics, but synchronization through the kernel (i.e. 
futexes) is invisible to TSan, so any locks you build would need to have 
TSan support. (External synchronization is the most common source of false 
positives even in normal circumstances.)

Re: Presentation interesting for w64devkit 2 months ago

From Christopher Wellons to ~skeeto/public-inbox

Thanks for sharing! Yeah, the Win32 debugging API is richer and more 
capable than ptrace, though it also doesn't quite fit into GDB's 
architecture. I recently used one little piece of dbghelp.dll myself in 

Poor native testing support explains the frequent regressions, as those 
would, in practice, only get caught through manual testing. I didn't know 
about that problem. It's also interesting that their best option for 
building GDB is cross-compilation, essentially the same conclusion I had 

Re: An improved chkstk function on Windows 2 months ago

From Christopher Wellons to ~skeeto/public-inbox

There are 5 defects, quite impressive for 15-ish lines of code. For the 
record, and for anyone following along, here is libgcc/memmove.c:

void *
memmove (void *dest, const void *src, size_t len)
  char *d = dest;
  const char *s = src;
  if (d < s)
    while (len--)
      *d++ = *s++;
      char *lasts = s + (len-1);

Re: An improved chkstk function on Windows 2 months ago

From Christopher Wellons to ~skeeto/public-inbox

Thanks, I didn't know about these. I found them in the GCC source like you 
said, and they're nearly 20 years old, but they're not actually present in 
libgcc.a. They were originally checked in outside of libgcc/, later moved 
there during reorganization, and it looks like maybe they only exist for 
GCC's own internal use (like the additional definitions in libiberty)? I 
don't see them included in builds, so maybe they're now vestigial.

While memset, memcpy, and memcmp look fine, libgcc/memmove.c has several 
defects, so I wouldn't want to use it anyway. I'm glad you pointed these 
out, though!

Re: [u-config/tcc] shorter syscall assembly 2 months ago

From Christopher Wellons to ~skeeto/public-inbox

Clever, NRK! Aesthetically I don't like the syscall number going last, but 
your macro fixes that up nicely. With inline asm, GCC and Clang inline the 
syscall functions, place arguments straight into the constraints, and 
basically figure this out automatically — a great advantage of inline asm.

> experimental and not for serious use,

Yup, that branch was to figure out how to do it without inline asm, then 
capture that knowledge. The no-libc side has changed since starting that 
branch, and even for semi-serious use would need some porting. Since I've 
gotten a better handle on _start, it would also reduce to two hand-written 

In an update I'd also probably just delete the string.h definitions and

Re: Callback contexts 2 months ago

From Christopher Wellons to ~skeeto/public-inbox

Interesting, and thanks for the port, Steadman!

> Did you test the BKPT opcode?

I had tried BRK but not BKPT, but it appears to be the same story. The 
instruction pointer is left on the break instruction, and so GDB (and 
LLDB) get stuck in a loop on the instruction. It seems they'd need special 
handling for it. I don't currently have access to a Windows Aarch64 system 
to see how it works as debugbreak under Visual Studio, but my cursory 
reading suggests they've got it figured out.