That is ABSOLUTELY NOT my doing. I am still angry about it.
Conversation
I also would never use src_buf / dest_buf. I used to do src/dst, but now I vastly prefer to just use register names.
1
3
(Because when I go back to edit it, it's a royal pain to figure out what registers are available for scratch or which names are actually the same register. So now I use the register name for everything and put a decoder ring at each main label.)
2
2
does there exist tooling to help people like you? one can imagine all sorts of great assembly-assist things, but the market would be so small it would be hard to justify producing it
2
4
I wanted a register-allocating, macro assembler for A64 with pluggable scheduler backends and couldn't find one so I wrote "sketchy" a few years ago
2
14
On top of there being few people wanting this tool, those few people can also all write their own instead of taking time to learn someone else's
1
3
Joe y would I use yr Perl script when i can write as good a perl script of my own??? it will do register allocation using 13 regexes.
1
2
7
Have you seen Samsung's kernel CFI implementation from before they gave up and moved to Google's upstream Clang CFI?
It's the most horrifying thing and by that I mean they pass compiled kernel code through a Python script using objdump to add CFI instrumentation as a total hack.
2
1
17
The only thing they actually implemented in the compiler (still GCC) was adding NOP padding for them to use in their post-processing Python script along with reserving at least one register. Extremely coarse-grained indirect call CFI + ret addr XOR with random value in register.
1
1
So, Clang CFI figures out all the functions that aren't indirectly callable from the fact that their address isn't taken and they aren't exported (works well with -fvisibility=hidden) and then enforces type-based CFI for the indirect calls where that's not the case.
1
1
Samsung's horrible CFI only prevented indirect calls not calling an actual function. It had no compiler analysis or anything since it was literally just a Python script post-processing the disassembled code (via objdump). Haven't seen many worse things done with computers.
Check this out:
github.com/djb77/samsung-
It's horrible. They have GCC reserve 3 registers and output a bunch of NOP instructions for them to use in this horrifying script. The conversation just happened to remind me of this nightmarish thing.
1
3
Could talk about all the sketchy assembly code / instruction parsing and mangling with regular expressions, totally unexplained bit operations, etc.
My nitpick is that they import the bisect module but then don't use it and roll their own binary search implementation instead.
3