28 ms·

Inline Assembly Dangers

122 points by fobes 2y ago

jamesfinlayson 2y ago
Annoying. I hit a somewhat similar snag on the weekend - inline assembly (in someone else's library) wasn't compiling because another library I was using had macros that collided with opcode names. Super-confusing error messages as a result.
wyldfire 2y ago
It always feels really tricky imo. Intrinsics are preferable if the functionality you need is at all possible with those. But I'd be surprised if you could easily clear the BSS with those. And who can remember what early clobbers is? I always forget and have to look it up because it feels especially subtle. It'd be neat if inline asm could use something like the triple quotes in other languages. Maybe it'd be easier to format text like this.
- saurik 2y ago
  In C++11 you can use R"( raw/multi-line strings for inline assembly.
- AshamedCaptain 2y ago
  > Intrinsics are preferable if the functionality you need is at all possible with those. But I'd be surprised if you could easily clear the BSS with those. You can do that with a plain memset. They are just using inline asm because they don't want the compiler to use stack/globals before they've had time to initialize them, which is very risky.
nynx 2y ago
Uh, why is this not a compile error? I’d expect the string to be concatonated, which would result in an invalid program.
- LegionMammal978 2y ago
  The first string is a comment, so all the strings after it just get appended to the comment text, until it finally hits the first newline. Quite an insidious mistake.
- dkersten 2y ago
  The strings are concatenated, it’s just that the first line was a comment, meaning the compiler/assembler saw all the next lines as part of the first. Comments don’t cause compiler errors, so no error here…
jijji 2y ago
why not just use the standard library functions, instead of these esoteric __*() functions, which although they may exist are probably not the right ones to be using.... it looks like you're trying to set the time zone and there's methods to do that, which is not the one you're referencing in your code...
- exmadscientist 2y ago
  The standard library functions have to be provided by someone. In bare metal/deep embedded work, that someone is YOU. So anything is possible. Anything. Though if you're unlucky enough to have untrustworthy hardware, or just not-yet-trustworthy hardware, that's usually enough to keep the nasal demons at bay (even they fear malfunctioning hardware), which is one small mercy.
corysama 2y ago
One of my favorite bugs was due to inline assembly! I once wrote a function that would crash only if you passed it the immediate value 4. Like `foo(4);` A variable containing 4 would not crash. The function was calling the Intel assembly instruction to byte-swap an integer. These days there’s an intrinsic for that. But, this was long ago and was written for platforms that didn’t even support POSIX. So, this function was serializing an integer to memory, byteswapping it in the process, and naturally advancing the destination pointer as well. The bug was that I forgot to mark the input register as dirty when I set up the inline assembly. An important thing to know about inline asm, and the reason it is so strongly discouraged these days, is that the compiler cannot see it. It’s a black box for the compiler with a limited set of manual hints — one of which I omitted. Therefore it really mucks up the compiler’s ability to pipeline instructions. And, that cancels out the performance benefits for short snippets of assembly. Anyway… I didn’t mark the register as dirty. Therefore, the compiler was unaware that it had been modified. So, if I called the function with a 4, it would run some black box inline assembly, write the value to memory, and then it needed to increment a pointer by the size of one integer. 4 bytes. How convenient! The compiler just saw that at compile time there was definitely a 4 in a certain register! And, the inline asm declaration didn’t declare that anything happened to that register, such as byteswapping it. So, let’s just use that “unmodified” register as a value to add to the pointer! Advancing a pointer by a byteswapped 4 makes for a quite invalid pointer. And, technically it was the next call to the serialized that would crash when it tried to write another value to that pointer.
- PhilipRoman 2y ago
  Sounds like this could be a nice extension to clang/gcc sanitizers, adding checks that certain registers are unmodified across inline assembly calls.
- exDM69 2y ago
  In addition to the missing newlines, the inline assembly code is also not correctly marking that it clobbers memory. It is probably not an issue for the entry point function, but the lack of it could mean the compiler is allowed to do incorrect optimizations.
- 2y ago
Grom_PE 2y ago
Inline assembly was very pleasant to write in Turbo Pascal and Delphi. In D language it looks okay too. In GCC, inline assembly has insane syntax. Probably on purpose, to discourage writing it.
- pjmlp 2y ago
  I never got the point of that weird syntax, I would rather reach out to a raw Assembly instead of dealing with such syntax. To add to your list, most C and C++ compilers on the PC world as well. Certain folks will mention it is because the compiler needs register usage info, yet PC compilers could and can, infer the usage as well, when parsing those asm blocks, or how intrisics are used (as alternative).
  - cesarb 2y ago
    > > In GCC, inline assembly has insane syntax. Probably on purpose, to discourage writing it. > Certain folks will mention it is because the compiler needs register usage info, yet PC compilers could and can, infer the usage as well, when parsing those asm blocks, The compiler can only infer the register usage info for known instructions, but the whole point of inline assembly in GCC is to use instructions the compiler doesn't know about (and many of these have implicit register uses which can't be inferred from just looking at the assembly syntax, you really need to know what the instruction does). And in some cases, the register usage can't be inferred even for known instructions; for instance, the registers used by a "call xyz" instruction depend on how the "xyz" subroutine was implemented (it probably has a nonstandard calling convention, otherwise there would be no reason for using inline assembly to call it). The "weird syntax" actually matches closely how known instructions are described within GCC itself, which makes sense since GCC inline assembly is all about teaching it about new (or non-standard) machine instructions (or pseudo-instructions), without having to modify and recompile the compiler.
    - pjmlp 2y ago
      Yeah, which kind of proves the point of the design of UNIX compilers, versus other platforms. I know GCC since 1995, and am I quite aware why such bad developer experience should be preferable kind of argumentation.
pjmlp 2y ago
And this is why inline Assembly done by GCC and clang sucks, and the inline Assembly done by most PC compilers, with first level support for opcodes, or instrisics is a great experience.
- SassyBird 2y ago
  It seems that MSVC supports inline assembly only on 32-bit x86. For amd64 and ARM they moved entirely to intrinsics.
  - vnorilo 2y ago
    The more I've written code close to metal (mostly SIMD for signal processing), the more I've grown to prefer either intrinsics or separate translation unit for assembly. If you want your code to intertwine with what the C compiler does, intrinsics are great. If you don't, .s is great.
    - pjmlp 2y ago
      Exactly, this is the right approach.
    - immibis 2y ago
      And the only way to use new instructions is to make them slow or to wait for a compiler update.
  - pjmlp 2y ago
    Yes, Assembly programming concatenanting strings, is horrible. Intrisics give the best of both worlds, without dealing with string based content. Actually ESPOL/NEWP from 1961 was one of the very first system programming languages with two key inovations, intrisics and unsafe code blocks.
    - SassyBird 2y ago
      I’m not a fan of concatenating strings either. I was thinking about the MSVC/Pascal-style inline assembly here, which isn’t based on strings. Correct me if I’m wrong, but I don’t think that you can guarantee a routine is constant-time by using intrinsics. You need asm for that. Asm that won’t be changed by the compiler. So you need to write an external asm file for that now, which is fair enough, but I just wouldn’t present intrinsics as all-around superior.
flumpcakes 2y ago
The real problem with inline assembly is that you really are flying blind and have to be an experienced enough to know what you're doing. The compiler can't help you much at all due to losing all type information. Saying that, I think it's a skill that we need to foster, at least for a few niches.
dist1ll 2y ago
Writing inline assembly in most languages is a pain. I think there's some real opportunity to make things more ergonomic. Basically taking the idea of HLASM and other high-level assembler projects, but actually bringing them into the modern era of languages and tooling. I would like to see a kind of "seamless" assembly feature, where asm instructions and ISA-specific registers could be made first-class objects (intrinsics are a weak version of this). Register-sized objects (like most numeric primitives, pointers, etc.) should seamlessly decay to the register in which they reside. Also, tooling and LSPs could be improved. Wouldn't it be nice if I can text-select a section of asm and the LSP shows me latency/throughput of the block on my desired target platform? Or maybe it does some proper static analysis like noticing dead writes, or maybe a refactoring action that expands a slow div into a more optimal instruction sequence.
ajross 2y ago
The bug here isn't really the fact that GCC inline assembly is a string replacement macro language, which surprises a lot of people coming from other syntax like MSVC. It's that the author wrote what looks to be a 20+ instruction entry and setup function and never once tried to verify it. You never write inline assembly without reading the resulting disassembly. It's like rule 0...
pjc50 2y ago
Why is this link dead for me?
- fobes 2y ago
  Hi, op here. Is there any sort of error message or status code? I use CloudFlare so it's quite strange if it simply didn't connect for you.
  - pjc50 2y ago
    Hmm, appears to be specific to my work PC which really doesn't like the SSL for some reason. Simply refuses to acknowledge that it's encrypted, rather than even presenting the certificate. Very odd since my own CloudFlare-fronted site which also uses their certificates works just fine. Sorry, I think this is very specific to my environment.
AshamedCaptain 2y ago
You really should not use inline asm to write your _start routine. The compiler can (and someday WILL, when you least expect it) use the stack, maybe in the prelude, maybe because one day it decides it needs to preserve one of the regs you claim you are using. This is undefined behavior all over the place. There used to be some attributes like 'naked' in some old compilers to avoid this... Also, no tests check if bss is zero? There's your problem... :)
antiquark 2y ago
A better title would be "Knife Juggling Dangers."
commandlinefan 2y ago
Code inside code is always a bad idea. Sometimes you can't avoid it (like with SQL), but in this case, if the file had just been an assembler source code file, this wouldn't have happened.

122 points by fobes 2y ago

Annoying. I hit a somewhat similar snag on the weekend - inline assembly (in someone else's library) wasn't compiling because another library I was using had macros that collided with opcode names. Super-confusing error messages as a result.

wyldfire 2y ago

It always feels really tricky imo. Intrinsics are preferable if the functionality you need is at all possible with those. But I'd be surprised if you could easily clear the BSS with those. And who can remember what early clobbers is? I always forget and have to look it up because it feels especially subtle. It'd be neat if inline asm could use something like the triple quotes in other languages. Maybe it'd be easier to format text like this.

saurik 2y ago
In C++11 you can use R"( raw/multi-line strings for inline assembly.
AshamedCaptain 2y ago
> Intrinsics are preferable if the functionality you need is at all possible with those. But I'd be surprised if you could easily clear the BSS with those. You can do that with a plain memset. They are just using inline asm because they don't want the compiler to use stack/globals before they've had time to initialize them, which is very risky.

nynx 2y ago

Uh, why is this not a compile error? I’d expect the string to be concatonated, which would result in an invalid program.

LegionMammal978 2y ago
The first string is a comment, so all the strings after it just get appended to the comment text, until it finally hits the first newline. Quite an insidious mistake.
dkersten 2y ago
The strings are concatenated, it’s just that the first line was a comment, meaning the compiler/assembler saw all the next lines as part of the first. Comments don’t cause compiler errors, so no error here…

jijji 2y ago

why not just use the standard library functions, instead of these esoteric __*() functions, which although they may exist are probably not the right ones to be using.... it looks like you're trying to set the time zone and there's methods to do that, which is not the one you're referencing in your code...

exmadscientist 2y ago
The standard library functions have to be provided by someone. In bare metal/deep embedded work, that someone is YOU. So anything is possible. Anything. Though if you're unlucky enough to have untrustworthy hardware, or just not-yet-trustworthy hardware, that's usually enough to keep the nasal demons at bay (even they fear malfunctioning hardware), which is one small mercy.

corysama 2y ago

One of my favorite bugs was due to inline assembly! I once wrote a function that would crash only if you passed it the immediate value 4. Like `foo(4);` A variable containing 4 would not crash. The function was calling the Intel assembly instruction to byte-swap an integer. These days there’s an intrinsic for that. But, this was long ago and was written for platforms that didn’t even support POSIX. So, this function was serializing an integer to memory, byteswapping it in the process, and naturally advancing the destination pointer as well. The bug was that I forgot to mark the input register as dirty when I set up the inline assembly. An important thing to know about inline asm, and the reason it is so strongly discouraged these days, is that the compiler cannot see it. It’s a black box for the compiler with a limited set of manual hints — one of which I omitted. Therefore it really mucks up the compiler’s ability to pipeline instructions. And, that cancels out the performance benefits for short snippets of assembly. Anyway… I didn’t mark the register as dirty. Therefore, the compiler was unaware that it had been modified. So, if I called the function with a 4, it would run some black box inline assembly, write the value to memory, and then it needed to increment a pointer by the size of one integer. 4 bytes. How convenient! The compiler just saw that at compile time there was definitely a 4 in a certain register! And, the inline asm declaration didn’t declare that anything happened to that register, such as byteswapping it. So, let’s just use that “unmodified” register as a value to add to the pointer! Advancing a pointer by a byteswapped 4 makes for a quite invalid pointer. And, technically it was the next call to the serialized that would crash when it tried to write another value to that pointer.

PhilipRoman 2y ago
Sounds like this could be a nice extension to clang/gcc sanitizers, adding checks that certain registers are unmodified across inline assembly calls.
exDM69 2y ago
In addition to the missing newlines, the inline assembly code is also not correctly marking that it clobbers memory. It is probably not an issue for the entry point function, but the lack of it could mean the compiler is allowed to do incorrect optimizations.
2y ago

Grom_PE 2y ago

Inline assembly was very pleasant to write in Turbo Pascal and Delphi. In D language it looks okay too. In GCC, inline assembly has insane syntax. Probably on purpose, to discourage writing it.

pjmlp 2y ago
I never got the point of that weird syntax, I would rather reach out to a raw Assembly instead of dealing with such syntax. To add to your list, most C and C++ compilers on the PC world as well. Certain folks will mention it is because the compiler needs register usage info, yet PC compilers could and can, infer the usage as well, when parsing those asm blocks, or how intrisics are used (as alternative).
- cesarb 2y ago
  > > In GCC, inline assembly has insane syntax. Probably on purpose, to discourage writing it. > Certain folks will mention it is because the compiler needs register usage info, yet PC compilers could and can, infer the usage as well, when parsing those asm blocks, The compiler can only infer the register usage info for known instructions, but the whole point of inline assembly in GCC is to use instructions the compiler doesn't know about (and many of these have implicit register uses which can't be inferred from just looking at the assembly syntax, you really need to know what the instruction does). And in some cases, the register usage can't be inferred even for known instructions; for instance, the registers used by a "call xyz" instruction depend on how the "xyz" subroutine was implemented (it probably has a nonstandard calling convention, otherwise there would be no reason for using inline assembly to call it). The "weird syntax" actually matches closely how known instructions are described within GCC itself, which makes sense since GCC inline assembly is all about teaching it about new (or non-standard) machine instructions (or pseudo-instructions), without having to modify and recompile the compiler.
  - pjmlp 2y ago
    Yeah, which kind of proves the point of the design of UNIX compilers, versus other platforms. I know GCC since 1995, and am I quite aware why such bad developer experience should be preferable kind of argumentation.

pjmlp 2y ago

And this is why inline Assembly done by GCC and clang sucks, and the inline Assembly done by most PC compilers, with first level support for opcodes, or instrisics is a great experience.

SassyBird 2y ago
It seems that MSVC supports inline assembly only on 32-bit x86. For amd64 and ARM they moved entirely to intrinsics.
- vnorilo 2y ago
  The more I've written code close to metal (mostly SIMD for signal processing), the more I've grown to prefer either intrinsics or separate translation unit for assembly. If you want your code to intertwine with what the C compiler does, intrinsics are great. If you don't, .s is great.
  - pjmlp 2y ago
    Exactly, this is the right approach.
  - immibis 2y ago
    And the only way to use new instructions is to make them slow or to wait for a compiler update.
- pjmlp 2y ago
  Yes, Assembly programming concatenanting strings, is horrible. Intrisics give the best of both worlds, without dealing with string based content. Actually ESPOL/NEWP from 1961 was one of the very first system programming languages with two key inovations, intrisics and unsafe code blocks.
  - SassyBird 2y ago
    I’m not a fan of concatenating strings either. I was thinking about the MSVC/Pascal-style inline assembly here, which isn’t based on strings. Correct me if I’m wrong, but I don’t think that you can guarantee a routine is constant-time by using intrinsics. You need asm for that. Asm that won’t be changed by the compiler. So you need to write an external asm file for that now, which is fair enough, but I just wouldn’t present intrinsics as all-around superior.

flumpcakes 2y ago

The real problem with inline assembly is that you really are flying blind and have to be an experienced enough to know what you're doing. The compiler can't help you much at all due to losing all type information. Saying that, I think it's a skill that we need to foster, at least for a few niches.

dist1ll 2y ago

Writing inline assembly in most languages is a pain. I think there's some real opportunity to make things more ergonomic. Basically taking the idea of HLASM and other high-level assembler projects, but actually bringing them into the modern era of languages and tooling. I would like to see a kind of "seamless" assembly feature, where asm instructions and ISA-specific registers could be made first-class objects (intrinsics are a weak version of this). Register-sized objects (like most numeric primitives, pointers, etc.) should seamlessly decay to the register in which they reside. Also, tooling and LSPs could be improved. Wouldn't it be nice if I can text-select a section of asm and the LSP shows me latency/throughput of the block on my desired target platform? Or maybe it does some proper static analysis like noticing dead writes, or maybe a refactoring action that expands a slow div into a more optimal instruction sequence.

ajross 2y ago

The bug here isn't really the fact that GCC inline assembly is a string replacement macro language, which surprises a lot of people coming from other syntax like MSVC. It's that the author wrote what looks to be a 20+ instruction entry and setup function and never once tried to verify it. You never write inline assembly without reading the resulting disassembly. It's like rule 0...

pjc50 2y ago

Why is this link dead for me?

fobes 2y ago
Hi, op here. Is there any sort of error message or status code? I use CloudFlare so it's quite strange if it simply didn't connect for you.
- pjc50 2y ago
  Hmm, appears to be specific to my work PC which really doesn't like the SSL for some reason. Simply refuses to acknowledge that it's encrypted, rather than even presenting the certificate. Very odd since my own CloudFlare-fronted site which also uses their certificates works just fine. Sorry, I think this is very specific to my environment.

AshamedCaptain 2y ago

You really should not use inline asm to write your _start routine. The compiler can (and someday WILL, when you least expect it) use the stack, maybe in the prelude, maybe because one day it decides it needs to preserve one of the regs you claim you are using. This is undefined behavior all over the place. There used to be some attributes like 'naked' in some old compilers to avoid this... Also, no tests check if bss is zero? There's your problem... :)

antiquark 2y ago

A better title would be "Knife Juggling Dangers."

commandlinefan 2y ago

Code inside code is always a bad idea. Sometimes you can't avoid it (like with SQL), but in this case, if the file had just been an assembler source code file, this wouldn't have happened.