Add more details on _y

[Arthur-Milchior]

I found

Let's inspect those stack/local variables

confusing. Indeed, the sentence mentions multiple variables, but a single one was inspected. It was even more surprising because when I entered print _y, I got the result 42. (I later understood that it is because the code was run twice, and the value assigned on first run)

For the sake of the consistency, it seems also interesting to mention what the learner would get if they were trying to read _y, its address, and maybe also why they could get the correct answer while the value is unitialized.

I considered mentioning that this statement could be checked by switching from 42 to any other number just before running. This would ensure _y can not be initialized.

[rust-highfive]

r? @andre-richter

(rust-highfive has picked a reviewer for you, use r? to override)

[eldruin]

Actually, I found the additional explanation about _y before its initialization rather confusing.
If the concern is that only x is inspected and the title says "let's inspect those" I would rather change that title.
However, I do not consider it confusing because the _y variable is also inspected just a few lines below.

[Arthur-Milchior]

The sentence I quoted was not a title. It was the sentence introducing the code excerpt. So I assumed that it was describing what the code was doing. It does not seems to refer to the whole section.
I'd be fine changing this sentence.

But, as a reader, what confused me most is something slightly more complex.
You wrote that _y is not yet assigned. Since I had gdb open while reading this, I found natural to check what would then occur if I just tried to print _y's value. And I got very confused, because I got 42. It could be a coincidence, but it would be a strange one. Especially since I could repeat the experiment and still got 42. I know that, when I use GDB on desktop, I would usually get random value for unitialized variables.
My first hypothesis was that the book was wrong for some reason. Maybe instead of line 13, it should have been break at line 12. Or maybe something changed since the book was written.

So, I assumed that if something confused me, I may not be the only one who gets confused by it, and wanted to help the next reader who may get lost at the same point.

Admittedly, I almost never run GDB over such code. Usually, I run it over real code I want to debug, and where it's guaranteed that the position in the stack was overwritten many time between two run. And anyway, I would not be guaranteed that the OS give the same physical address in memory to two different runs. So it seemed interesting too to note that there is a difference between embedded software and software running on top of OS.

However, while I believe that this information is potentially interesting for future reader, I don't claim my wording is the best one ,and I'd be very happy to see it improved. I hesitated between creating an issue or directly a PR, and assumed a PR would be simpler to show exactly what extra information I'd find useful, even if it would not be merged as-is

[eldruin]

I understand. Thank you for the explanation.
On balance, this is an introductory book to microcontrollers so the target audience are rather beginners.
The section concerning this PR is potentially the very first program a user flashed onto their device and even the first time they fire up gdb. Certainly is the first program in the book.
This is why I think the additional explanation about uninitialized-or-not memory and multiple runs rather adds confusion to a mind where a lot is already going on.
Whether this explanation would be fine in a different form, I do not know. As it stands. I would rather not include it.
As I said, I would be fine with some rewording of the introductory text if deemed unclear.
Any other opinions @rust-embedded/resources?

[BartMassey]

For me, the confusing part of the existing documentation is the claim that _y is not initialized. This may not be true in practice: the compiler may go ahead and initialize it.

That's not what seems to be happening here, though: the assembly seems to show that the 42 is indeed a coincidence.

        movl    $42, -8(%rsp)                                                   
.Ltmp24:                                                                        
        .loc    8 3 13 is_stmt 0                                                
        movl    $42, -4(%rsp)                                                   

All in all, I think it would be better to just reword this to avoid the whole issue of when things get initialized. It's a confusing topic that's a little out of scope at this stage of the game, I think.