Show only useful digits in 64-bit addresses

[10110111]

Currently 64 bit addresses are displayed with ever-zero digits representing bits 48-63. But currently (and I guess this won't change soon) only 48 address bits are supported by x86_64 CPUs. Addresses not in canonical form even produce #GP(0) when referenced. And the four extra zeros take away screen real estate.

So this request is to only show 64 bit mode addresses as 48 bit numbers, not full 64 bit.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[eteran]

This is a fair enough point, perhaps a configuration option to allow only showing lower 48 bits or similar.

[10110111]

I have a working patch for QDisassemblyView https://github.com/10110111/edb-debugger/commit/abff8fe9c9444066fd801cda7628ef865442c579, but there's a problem that this doesn't apply to QHexView, and I can't even avoid repeating the code if I change QHexView due to it being in a separate repository. Maybe this should be done once in QHexView, and then QDisassemblyView could just call the functions from there? This would be especially important if we add a configuration option for this, so that the display would be consistent in different views.

[10110111]

Would you accept a solution where formatAddress method (made public) is only in QHexView, then EDB sets the configuration option in QHexView, and QDisasemblyView just calls the method of QHexView? This would unify the (already similar) UIs of QHexView and QDisassemblyView and potentially allow for some other changes like digit grouping without duplication of code.

[eteran]

Let me think on this a bit. If possible I'd like to avoid unnecessary coupling between edb and QHexView since they are separate projects.

That being said, I completely agree with your goal of code de-duplication.

I don't know how it would effect performance, but I in trying to consider alternatives, I am imagining perhaps have a "setAddressFormatter" function which would take a function pointer/lambda to use instead of the default formatting function.

If we did this for both QHexView and QDisassemblyView, then we could have a common formatter. That being said, I don't know if having an indirect call for each address drawn would be horrible for performance, so I'm a bit torn :-/

I'll continue to think about how I'd like this resolved though (hopefully soon, this bug is one that I'd like to have a good fix for since leading 0's in addresses only waste space on the screen!)

[10110111]

BTW, maybe the formatter should also be able to provide color. Otherwise, if address colors finally are made configurable, the configuration would have to be done separately for hex views and disassembly (and that wouldn't mean just the only color existing now: it could be e.g. color+background for current instruction, for breakpoint, default, etc.).

[10110111]

Funny, just now noticed that there're addresses like 0xffffffffff600000 in user space. Such a page is in particular mapped for [vsyscall]. Still, the leading ones are just "sign extension" of the low 48 bits — the way canonical addresses are obtained, so it still makes sense to hide them.

[eteran]

Hmm, that may be confusing with anyone not 100% familiar with canonical addresses on 64-bit.

So, perhaps there would be two settings:

1. shorten addresses with leading 0's
2. shorten addresses with leading 1's

I'm not too concerned about it though, just thinking out loud :-)

[10110111]

The only problem with variable address length might be that the line1 will hide the least significant nibbles when we jump from positive address to negative. And hiding it, it might render ffffffffff600000 like ffffffffff60.

[eteran]

Hmm,well the plan is to show 6 digits regardless. So it will be apparent that it is an address > 32-bits. So yea, I think I'm with you, though I'd like an option to enable/disable the shortened addresses in case some users just like having the longer ones.

Also, just as note, we probably want to give the data-view tabs similar treatment for consistency.

[10110111]

Right, not even probably: this is must have IMO. They all have a similar look (color etc.), so they must be consistent.

[slacker69]

I also like this idea. I don't think it's a "must have" for me, but more of a I would very much like to see:) some of the addresses look a bit cluttered with all the 0x000... in front of it. The option to have both would be the best. Thank you.

[eteran]

@10110111 I know this feature is a bazillion years old... but I'm on it! Starting to implement it, QHexview has the feature and I've started to see how to best add it to the other places too. It'll all be "enabled" as a configuration option at once though so we don't have a mixed implementation!

[eteran]

Worth noting that regarding your question of settings and "where does the address formatting code go" we currently have a mixed bag.

QHexview is its own thing which has to have each setting individually set.

QDisassemblyView is half and half, some settings are set by edb, some it just grabs directly from the edb::v1::config() object. We should probably move this widget to be more like QHexView in that settings should be set when it is created, and then synced when configuration/debug attach events occur (we can just TELL the width when we attach "this is 32-bit" like we do with QHexView.