jmorse2 · HackerTrans

il y a 3 ansdiscuss

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...

jmorse2

il y a 4 ansdiscuss

> 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

jmorse2

il y a 4 ansdiscuss

> 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.

jmorse2

il y a 4 ansdiscuss

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.

jmorse2

il y a 4 ansdiscuss

> 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

jmorse2

il y a 4 ansdiscuss

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.

jmorse2

il y a 4 ansdiscuss

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).

jmorse2

il y a 4 ansdiscuss

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

jmorse2

il y a 5 ansdiscuss

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...

comments