jmorse2's comments

As there's something about branch prediction on the front page right now, "The slow winter" [0] is well worth a read too because a) We should remember the magma people are waiting for our mistakes, and b) the branches really did make a pact with an adversary, resulting in the spectre CPU vulnerabilities we know and love today.

(It really is worth a read; James Mickens is indeed a national treasure).

[0] https://scholar.harvard.edu/files/mickens/files/theslowwinte...

> I'm referring to all the cases where the compiler obviously should know where the value is, yet the debugger somehow doesn't.

Soooommmee of this can be explained by the design decisions in the compiler not lending themselves to working well with debug-info, as explained here [0] (shamless plug), from about 3 minutes in there's an example of a scenario where a variable location has to be discarded out of conservative precaution (4:40 to 7:00), rather than because it's definitely been optimised out.

[0] https://www.youtube.com/watch?v=yxuwfNnp064&t=45s

> I haven't looked at DWARF for ages. Can it describe the situation that a variable is valid (in some register) in the beginning of a function, but then goes "out of scope " in the middle of the function?

Yes, with DW_OP_entry_value used in location expressions to indicate that the variable value is in a certain location on entry to the function. However -- debuggers typically don't store all register values on entry to all functions, so usually the stack frame up needs to be instrumented with call site information indicating where the debugger can find longer-term stored copies of the arguments.

In TFA you can see that happening correctly wherever there's a "@entry" annotation from gdb for an argument, in some cases there isn't a longer-term copy of the value further up the stack, in which case the variable remains optimised out.

Assuming you're referring to the articles first example, I suspect optimised-out is the correct outcome in that situation. The program is stopped at the start of one function, and the author is looking one stack frame up at this code:

     0x0000564ab5d178c4 <+52>:    callq  *%rax
  => 0x0000564ab5d178c6 <+54>:    mov    %rbp,%rdi

%rsi indeed hasn't been clobbered when the call executes, but it becomes liable to be clobbered during the execution of the callee. By the next instruction (at +54) there's no guarantee that %rsi contains the correct value, thus it's best reported as optimised out. The author is handily stopped at a point in time between the two instructions displayed above (in a lower stack frame), where the correct value happens to be in %rsi, but this is not guaranteed to be always true.

> they aren't (again, AFAIK) doing anything about it

Person slightly doing things to LLVM checking in -- the three points you list are compelling, because it's always going to be difficult to describe one program (source) in terms of a vastly different (optimised) program. Do you think there's mileage in showing the developer a partially optimised program [0] instead of trying to perfectly describe the source? It'd be easier to describe in debug-info, and possibly easier for developers to identify unexpected changes to the code they wrote.

[0] "Non-Transparent Debugging of Optimized Code", 1999

Possibly closer to the mark in terms of scripture is Ezekiel 38, which specifies that the Jews are to have returned/gathered from exile/dispersion and be living in peace ("unwalled cities") before an invasion/looting from the north. Of course, it only specifies the movement of peoples, not the political configuration of the land.

I've got a copy and still use it sometimes -- being able to immediately see nearby words (like "glad", "gladly", "gladness") is quite useful, which you'd miss just searching for "glad". Being able to see all uses on a hardcopy in a fixed position that doesn't scroll is helpful too, I find it harder to rationalise big lists when they're scrollable.

(I also use it to explain type checking to friends, given the number of times I've looked up a Hebrew word in the Greek dictionary, or vice versa).

(NB: the developers guide says to ping if there's no activity for a week)

To reinforce this, one of the statistics that the beeb have wheeled out is that in the most vulnerable group being vaccinated (in the UK), aged 80+, one in ten of them will die regardless of covid in the next year. Quoted from "How to vaccinate the world -- Vaccine Hesitancy" [0] from 12 minutes in to 15 minutes. (And because it's BBC sounds, for some reason it randomly skips episodes when I load the page).

The entire series is well worth a listen, data driven and statistics heavy.

[0] https://www.bbc.co.uk/sounds/play/m000qblw

Edit - because the beeb want registration, alternate link: https://podcasts.apple.com/gb/podcast/vaccine-hesitancy/id15...

> I'd like to learn more about this. Maybe contribute to the compiler and fix this issue.

You need to create a call to the `llvm.dbg.declare` intrinsic that connects the stack variable alloca to a DILocalVariable metadata node, and place the call after the stack variable alloca. The rest of LLVM will handle tracing the stack location through the compiler to the output, including the alloca being promoted.

See: https://llvm.org/docs/SourceLevelDebugging.html#debugger-int...

Thanks for finding all those bugs! I see the BI / SI / LI invariances you define are looking for program states that aren't present in the unoptimised program, while PI is looking for the absence of information that is in the unoptimised code. Do you think it will be possible to define and search for invariants that involve program states that are in the unoptimised program, but are presented in in the wrong way in the optimised program? For example variable values being presented at the wrong time, or stepping behaviour that misleads developers.

It'd be great to hunt those kinds of bugs, however it's hard to define what the "right" behaviour would be in those circumstances.

It's DWARF-5 only: variable values can be expressed in terms of a parameters value on entry to the function. Depending on the circumstances, that value can be recovered from further up the stack frame.

(Ninja edit: although tuning for GDB might coax LLVM to emit the pre-standardised form, without DWARF-5).

Biblical sources describe tin as being sourced from Tarshish [0], a remote island that traded with the Phoenician naval merchants in Tyre. Plus as wtracz' sibling comment indicates there's a potential Phoenician connection with Cornwall, it isn't especially unlikely.

[0] https://www.blueletterbible.org/esv/eze/27/12/s_829012

On the other hand, Herodotus describes islands off the north/west of Europe "from which we are said to have our tin" [0].

[0] https://en.wikipedia.org/wiki/Cassiterides