Hacker News Reader

This is a very neat hack, but it breaks in the presence of:

- Inlining: it will work but the defer will be executed at the end of the caller function, which may not be what you expected.

- Tail call optimization: same issue. (You mention in a comment that you use a dummy asm statement to prevent the call to `__defer` itself from being tail-call optimized, but there's still an issue if one defer-using function tail-calls another defer-using function.)

- Function outlining aka hot/cold splitting (currently implemented in LLVM): arbitrary chunks of a function can be split out into their own functions; if one of those does a defer, the cleanup might be run too early, considerably more dangerous than too late.

- Various CFI (control-flow integrity) implementations that are specifically designed to prevent the return address from being overwritten (by exploits).

- Interprocedural register allocation (-fipa-ra in GCC) if __defer gets inlined or analyzed via link-time optimization: The compiler can make assumptions that functions won't modify certain registers that the ABI would normally allow them to modify; this will be violated if it unexpectedly jumps to __defer. This is fixable by marking __defer as __attribute__((noipa)) or reimplementing in assembly.

- Targeting WebAssembly or BPF or other high-level machines that don't support overwriting return addresses.

- Compilers that don't support inline assembly (MSVC).

EDIT: - Targeting ARM if the compiler happens to stash the return address in an unexpected location. You can't fix this by writing to LR like you suggested; the return address needs to be in LR when you execute the ret instruction, but the compiler doesn't need to keep it there for the whole function, and usually won't. Instead, it will usually save it to the stack frame, and load it back before returning, potentially using LR for completely unrelated purposes in between. So usually you can modify the return address by using __builtin_frame_address just like on x86. But that's an implementation detail; it could decide to keep a copy in another register, and move that to LR when returning. Not sure if any compilers actually do that, though I think I might have seen something like that on PowerPC.

Your approach is also relatively slow, since the cleanup code can't be inlined.

(If you're going to use a GNU extension for inline asm, why not just use the GNU extension __attribute__((cleanup))? It's block-scoped, but it doesn't disable any optimization passes or anything since the compiler knows about it, it's portable, and it doesn't have the problems I mentioned.)

Thank you for the thorough response.

Inlining, tailcall, hot/cold: None of these are issues. They don't change the fact that memory passed to gc() will be freed. Worst case scenario is the can gets kicked down the road, which is relatively easy to predict. See https://gist.github.com/jart/5aba7fc72c7b6781dadd5949c289a0b... So long as you're not using this technique to unlock mutexes, you'll be fine.

Developers who are required to use CFI need to reach out to their policymakers for authorization to modify return addresses before using the gc() macro. Folks required to use MSVC can use the existence of the gc() macro as compelling evidence for their bosses on the benefits of switching to GCC or Clang.

I'll take you on your word on IPA. I've added a comment to the Gist making sure folks who use it are aware. Thanks for the awesome info on ARM. That's good to know. Also I believe the code is fast.

I like the gc() macro because it can be used in expressions. I find __attribute__((__cleanup__)) unpleasant since it has strong opinions about how variables and cleanup functions need to be declared.

> So long as you're not using this technique to unlock mutexes, you'll be fine.

This does not sound good.

In addition, it is worth mentioning that your hack will probably break the return stack buffer of the x86 superscalar processors.

While a "defer" implementation would have neither of these two flaws.

No doubt it's a pretty neat hack, but I would be sceptical about using it extensively in place of a "defer".

> Inlining, tailcall, hot/cold: None of these are issues. They don't change the fact that memory passed to gc() will be freed. Worst case scenario is the can gets kicked down the road, which is relatively easy to predict. [..] So long as you're not using this technique to unlock mutexes, you'll be fine.

That's true for inlining and tailcall, but not hot/cold, since it can make cleanups execute earlier than expected rather than later. This happens if: (1) some chunk of the function is extracted into a separate function; (2) the chunk contains a call to defer; and (3) some code which is not in the extracted chunk, but executes after it, expects the cleanup to not have run yet. See this example:

https://gcc.godbolt.org/z/1ro1z6

To be fair, Clang does not enable this optimization by default, and it might get replaced by a different implementation of hot-cold splitting [1] which happens to not suffer from this issue (because it operates later in the pipeline, essentially splitting blocks at the assembly level rather than the IR level).

On the other hand, GCC does enable a form of hot-cold splitting by default, via -fpartial-inlining, but it's limited to splitting out suffixes of the function (i.e. regions starting somewhere in the function and including everything in the function that can be executed from then on), rather than arbitrary regions. Therefore, it can't run into the problematic case where non-extracted code runs after extracted code. Still, this is just an implementation limitation that could be lifted in the future.

> I like the gc() macro because it can be used in expressions. I find __attribute__((__cleanup__)) unpleasant since it has strong opinions about how variables and cleanup functions need to be declared.

Fair enough; I do agree on that point. (I wish GCC had a way to either use attribute cleanup with C99 compound literals, or somehow declare variables that live within statement expressions as having their lifetime extended to a surrounding block… Maybe what I really want is a better macro system. Or the native `defer` feature proposed here, but I doubt that will ever happen.)

[1] https://lists.llvm.org/pipermail/llvm-dev/2020-August/144012...

Please note the intended use case was this:

    #define gc(x) ({ auto y=x; defer(free, y); y; })
    int *buf = gc(malloc(sizeof(int)));
    if (coldpath) {
        ...

It's a bit of stretch to leak memory doing this:

    int *buf = malloc(sizeof(int));
    if (coldpath) {
        defer(fake_free, buf);
        ...

Your point is otherwise valid. It appears a nonstandard nondefault LLVM extension can break the macro under circumstances that are difficult to imagine happening in practice. Here's why LLVM is wrong. It surgically removes a chunk of code from the middle of a function, turn it an external function, and then emits a synthetic call. It should jump to the cold block and jump back. The amount of code I'm seeing it generate just to handle the abi boundary it needlessly created is almost as large as the chunk that's being outlined.

Godbolt's website doesn't show this, but if you pass -S to clang-10 you'll notice other suboptimalities exist in the way this LLVM extension was implemented. For example, it doesn't emit .section directives to relocate the cold code, which is half the point of hot cold pgo style optimizations, since I recall Google building the thing to not have their web-scale static binaries paging hundreds of megs of cold code off disk.

LLVM is doing great work, but still has so much catching up to do compared to GCC on the code generation. GCC 9+ does cold optimizations by default, but only to relocate cold noreturn error handling paths into .text.unlikely. That's not an issue. I can't say for certain what it does if you generate and pass and optimization profile.

This is a great answer, and this issue highlights pretty well the problem that can arise when people reason about C as if it was just ”portable assembly”.

The original goal of C was to allow writing programs in a platform independent way, i.e. without having to write different code for different arches.

Also, there is no inline assembly support in standard C, just in various compilers.

Interestingly, C++ does have an asm declaration.

It exists, but the meaning is implementation defined.

https://eel.is/c++draft/dcl.asm

>> The original goal of C was to allow writing programs in a platform independent way, i.e. without having to write different code for different arches.

I think it was meant to be a portable language, not to let you write portable code. With the size of standard types being machine dependent you couldn't write completely portable code, but you could write C on a lot of hardware.

It's like how 8 bit computers all had BASIC but weren't compatible. If you knew one it was easy to get going on another because at some level it was all BASIC.

While interesting, such a construct is obviously unsuitable for inclusion in the C standard nor can it be relied upon when writing portable code.

I never proposed that some code I posted to Gist be part of the C standard. I'm flattered however that folks are considering it for that purpose!

Nobody's proposing your code for the C standard. The original article is proposing an addition to the standard. Your comment argues that programmers don't need the addition to the standard because there is a non-standard, non-portable hack. That is not a good argument against an addition to the standard.

The onus is on the proposer. C is simple and should stay that way. If someone is proposing C needs to be altered (which is about the most conservative language there is when it comes to adopting features) then that person should have good arguments as to why there's no other way. Otherwise it belongs in C++. If whipping up a few lines of asm for my local architecture solves the problem, then that weakens the proposal.

Maybe instead the C language committee should be focusing on standardizing the RMS notation for the asm() keyword which makes this epic hack possible. https://gist.github.com/jart/fe8d104ef93149b5ba9b72912820282...

The RMS notation is pretty icky, though, and it of course only works for x86 as well. I actually like Rust's asm macro quite a bit: https://doc.rust-lang.org/unstable-book/library-features/asm....

Your Gist is excellent either way, thanks for compiling it. I'll probably reference it whenever I write inline asm now ;)

Glad I could help!

Rust asm syntax looks nice, but the syntax is just the tip of the iceberg. asm() is almost a misnomer. Its true power is the constraints system that lets us control GCC/Clang internal algorithms. You may have noticed that the defer() macro uses asm() with an empty string!

It's such a general tool that's become so prevalent as a practice (since Stallman invented it in the early 90's) that I would surely hope it's on the radar of language committees by now. If these definitions and mnemonics can be formalized or at least clarified by standards bodies, then they should be.

I think your implementation is really, really cool. Similarly I spent a good half hour bumbling through Cosmopolitan. Love what you've built.

IMO, the fact that asm() is used for a bunch of things unrelated to inline assembly -- but to your point, instead for changing compiler behaviors is more of an argument for exposing additional __attributes__, annotations and so on, rather than adding explicit support for asm() to the standard. This violates the principal of least surprise, and IMO, serves to further confuse rather than bring some predictability to C.

I'd suggest also that C should embrace some movement in the standard rather than agreeing to leave things as is forever and stapling legs onto the octopus that is C++. There was a good writeup here a while ago from someone involved with the committee, that they've gotten to the point where introducing new warnings for obviously broken behavior is off the table because they want to be warnings-compatible from release to release.

What I'm saying is I would rather see exposed intrinsics, primitives and other meaningful source annotations than codifying the spooky action at a distance of an empty string asm() call in the C standard. And if we're going to modify the standard there's a lot of low-hanging fruit I'd love to see cleaned up first.

[edit] I'd also like to add that I agree with your thesis that if this can be built with the tools provided instead of modifying the standard, that the onus is on the proposer. Based on some of the other analyses here it seems like it can't really be done in a universal way, but I'm open minded.

Hmm, that’s actually a very interesting viewpoint on inline assembly, and it’s certainly something that I think may be useful to have. That being said, the ergonomics of actually using it are still kind of poor, even putting aside the strange register names and such, since it’s obviously not really designed to do this. And the other concern I would have is that compilers tend to be fairly conservative when seeing such constructs; I think even with operands specified as much as possible there are still substantial gaps in what you can express to the compiler and also how much the compiler actually cares that you marked a particular register set as being clobbered-it might just spill more or be conservative if it doesn’t want to deal with your constraints. I should probably look to see if compilers treat it better today.

You're not alone in feeling that way. There's a very short list of people who've ever taken the time to fully grok Richard Stallman's Math 55 assembly notation, and they mostly work on projects like the Linux Kernel and glibc. It's designed to do anything. I've been using it the past few days to retool the standard x86_64 compiler to generate 16-bit boot code for The LISP Challenge. https://github.com/jart/cosmopolitan/blob/b6793d42d5ed6b4f78...

I think perhaps this is the wrong way to look at it -- having it as a standard way to do things built into the language simplifies this (not everybody needs to know tricks) and also most likely will be more portable across platforms.

Looks extremely cool. Presumably __cleanup__ is more robust in a GCC environment though?

That gist looks interesting. You said it is from cosmopolitan, I assume it has the same license as it. Thinking about toying with that defer implementation. Looks fun.

Though I still do it all manually, and am looking for ways to automate it.

The Gist is now updated with an ISC license. So it's very permissive. Enjoy! Feel free to contact me anytime too, if you get interested in hacking on this stuff.

I don't think "C shouldn't implement X" and "because X is trivial as an asm macro" are two sentences that make sense together.

tangential suggestion: if the the first line of the cosmopolitan README after the title was the description "fast portable static native textmode executable containers" then that would help newcomers more quickly understand what the project is about. i skim-read through the README and was still fairly puzzled about what the purpose of a cosmopolitan was before i saw that description hiding in the margin.

Thanks for the feedback! The README has now been updated: https://github.com/jart/cosmopolitan/commit/fd22e55b42503093... It could use more work though. See also https://justine.storage.googleapis.com/ape.html and the HN thread about it last month: https://news.ycombinator.com/item?id=24256883

Can this be made to work on ARM as well?

ARM implementation would be fun to look at as well.

Yes, absolutely! In the case of Arm, it would need to be a pure macro (i.e. no external __defer function) since ARM ABI uses a register to store the return address. Then the unwind code would need to save the return registers x0 to x7 each time it calls free() or whatever function is being deferred. I'd write it for you, but I don't use ARM.

You need to disable inlining. __builtin_frame_address can give surprising addresses when inline enabled. The code itself is likely not be wrong, but you won't confined to the lexical scope as if you see in the code (the defer can be triggered when the parent function returned).

Disclaimer: I haven't looked at the code too closely.

Inlining gives you the ability to control how "pooled" the free() operations end up being. You don't need to disable inlining. You just have to be mindful of how much power this macro gives you. For example, if a function that calls gc() is being called from within a loop, then it's a good idea to make sure that function isn't static.