Uhh what?

Posted Oct 8, 2024 14:29 UTC (Tue) by atnot (subscriber, #124910)
Parent article: Efficient Rust tracepoints

> This was rejected for introducing code duplication

I was curious and clicked on through to see the more detailed reasoning, since in my recollection, the asm involved is just nop instruction with a linker annotation. I found none of that, only:

> I really think that whoever created rust was an esoteric language freak. Hideous crap

Which I found a bit confusing because I have recently been assured that this sort of thing was merely a single isolated incident. It does not seem conducive to a productive discussion either way.

Not up to me to decide what code a maintainer accepts of course. But if anyone has a more substantive reason why a nop instruction is an undue burden on the whole kernel, more so than the described horrible sed and preprocessor hacks, I'd love to know.

Uhh what?

Posted Oct 8, 2024 15:39 UTC (Tue) by jgg (subscriber, #55211) [Link] (4 responses)

Each arch has it's own asm, so it is not just one asm, but 21 copies. Then it is the overall slippery slope principle, if rust can duplicate C code because it has technical issues with consuming it directly, then where does it end?

Presumably the horrible sed will work on all arches and scale as we add more arches. But somehow I think this is just the tip of the iceberg on these issues and the sed script will have to evolve into something much more powerful. We have many little tricky inline assembly things and wrappering them in function calls is not the right thing to do, they are tricky inline assembly for a good reason.

Uhh what?

Posted Oct 8, 2024 17:55 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (3 responses)

I have to wonder if Rust (or maybe even C) could somehow grow a compiler intrinsic to emit "exactly N bytes of NOPs that won't be optimized out, or else a compiler error if no single-byte NOP is available and N can't be made from the available multi-byte NOPs." Is that good enough for tracepoint support, or do you need more specific guarantees than that?

The other question, I suppose, is whether LLVM IR and/or GCC's IR have support for such a thing, or if it would need to be invented first.

Uhh what?

Posted Oct 8, 2024 18:30 UTC (Tue) by daroc (editor, #160859) [Link]

What exactly is required for a tracepoint depends on architecture — and in particular, the details of how the instruction decoder synchronizes with memory — but for x86_64, just a sequence of nops is not enough, it needs to be one single nop of the right size (and aligned, if I recall correctly). Otherwise, you can end up executing part of the jump target as though it was an instruction, if the instruction pointer is inside the sequence of nops when the replacement happens.

Luckily, x86_64 has nops of every size up to ... 12, I think it was? So in practice, you just need to make sure you choose the right size nop.

Compiler-generated NOPs

Posted Oct 8, 2024 20:50 UTC (Tue) by riking (guest, #95706) [Link] (1 responses)

This does actually exist already: https://doc.rust-lang.org/beta/unstable-book/compiler-fla... places NOPs at or before the start of a function. The problem is putting them in the middle of a function.

Compiler-generated NOPs

Posted Oct 31, 2024 13:43 UTC (Thu) by sammythesnake (guest, #17693) [Link]

How about an inlined function that starts with the required NOPS and then does nothing? Is that something available in Rust and would it do the job...?

Uhh what?

Posted Oct 9, 2024 12:26 UTC (Wed) by intelfx (subscriber, #130118) [Link] (3 responses)

>> I really think that whoever created rust was an esoteric language freak. Hideous crap

Sad. This is disappointing (yet not really unexpected).

Uhh what?

Posted Oct 10, 2024 5:00 UTC (Thu) by milesrout (subscriber, #126894) [Link] (2 responses)

Speak for yourself. It doesnt disappoint me. There is no rule that everyone has to like everything. People have said the same sort of thing about every programming language. If you are going to be upset that some people dont like your pet language you are going to be perpetually upset.

Uhh what?

Posted Oct 10, 2024 8:36 UTC (Thu) by fishface60 (subscriber, #88700) [Link] (1 responses)

> There is no rule that everyone has to like everything.

This isn't disappointment that someone doesn't like something you do, it's disappointment that they have forgotten all their manners.

Uhh what?

Posted Oct 31, 2024 13:45 UTC (Thu) by sammythesnake (guest, #17693) [Link]

Paddington would suggest that a Long Hard Stare might provide time to remember them :-P

Uhh what?

Posted Oct 10, 2024 5:34 UTC (Thu) by mb (subscriber, #50428) [Link]

>> Urgh, more unreadable gibberish :-(

>> I really think that whoever created rust was an esoteric language freak. Hideous crap

>> the creator of Rust must've been an esoteric language freak and must've wanted to make this unreadable on purpose

Well, thanks for giving me yet another confirmation, that it was correct for me to leave the kernel development community behind.
I'm not interested in this kind of nontechnical nonsense replies anymore.

I would actually like to work on R4L, but I don't like being insulted anymore. Too old for wasting my time on things like that. Thanks.