Debugger: Memory viewer shows wrong address offset when changing bytes per line

[Truevideo]

In the memory viewer window, when changing the bytes per line with CTRL+P / CTRL+O the address offset goes all over the place when its value is other than 0.

Example displaying 16 bytes per line:

Change to 15 bytes per line:

I believe the base address should remain unchanged.

Thanks

(edited for clarification)

[galibert]

Why do you believe that? 6dad + 0d15 = 6dbc... OG.

…

On Wed, Apr 7, 2021 at 1:54 PM Truevideo ***@***.***> wrote: In the memory viewer window, when changing the bytes per line with CTRL+P / CTRL+O the address offset goes all over the place when its value is other than 0. Example displaying 16 bytes per line: [image: image] <https://user-images.githubusercontent.com/53125775/113861958-1b1b3580-97a8-11eb-8d07-190ea18c8ce0.png> Change to 15 bytes per line: [image: image] <https://user-images.githubusercontent.com/53125775/113862022-3128f600-97a8-11eb-97ba-99fecb94d3b8.png> I believe the offset value should remain unchanged. Thanks — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7941>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGSF4IEWWSGWOBY2SBNFNLTHRBWLANCNFSM42QUPBJA> .

[Truevideo]

@galibert I can see that the offsets within lines are correct, but this is not the point I was trying to make. Changing the number of bytes shown per line shouldn't affect the base address (in my example 7500):

As you can see the first address displayed is 6DAD instead of 7500

[cuavas]

Do you mean the memory offset of the top line changes? That’s because it’s keeping roughly the same top line number – 0x7500 / 0x10 = 1872, and 0x6dad / 0xf = 1871, they’re about the same number of lines from the beginning of the address space. Re-evaluating the address expression isn’t necessarily the right thing to do either because you may have scrolled away from it. If you want to to jump back to the address expression you can hit enter again.

[Truevideo]

@cuavas I'm afraid I'm not quite following you here. You mean displaying the same number of lines from the beginning of the address space was the intended behaviour? That wouldn't make much sense at all. How is that even useful?

I do see how there could be a mismatch when scrolling away from the base address and changing the bytes per line afterwards. That would be kinda expected.

Anyway I'm manually re-evaluating the address expression by hitting enter as suggested. It's just a very minor inconvenience in the grand scheme of things, but I'm fairly confident there's something broken here.

In any case thanks for chiming in.

[cuavas]

You mean displaying the same number of lines from the beginning of the address space was the intended behaviour? That wouldn't make much sense at all. How is that even useful?

It’s not so much because it’s useful as that it’s relatively simple to implement and not very error-prone.

Anyway I'm manually re-evaluating the address expression by hitting enter as suggested. It's just a very minor inconvenience in the grand scheme of things, but I'm fairly confident there's something broken here.

It’s not “broken” in that the code is behaving as the developer intended. There are various other niggles with changing bytes-per-line related to the way the window width is handled.

The objections are to the wording you’ve used:

• @galibert interpreted “shows the wrong address offset” as meaning that you believed the addresses displayed in the gutter to be incorrect – the addresses are correct
• My objection is that this is really a feature request. It’s working as the original developer intended, but you want different behaviour. You want it to automatically scroll so the topmost visible line includes the address of visible before changing the number of bytes per line.

[Truevideo]

Fair enough. Let's not quibble over semantics though.