Community
Participate
Working Groups
Currently user cannot scroll to the last addressable byte when addressable sizes > 1 octet, due to IMemoryBlockExtension#getAddressSize() returning bytes instead of octets. ------------------------------ Debug Platform memory API specifies "bytes" with the implicit reference to MemoryByte. The later is clearly a mapping to java byte (i.e. for CDT would be "octets"). All the memory renderings implementation to make the same assumption, i.e. IMemoryBlockExtension#getAddressableSize() and IMemoryBlockExtension# getAddressSize() return "octets". The two equivalent method from GDB API, IGDBMemory.getAddressSize() and IGDBMemory2#getAddressableSize, are inconsistent with this regard. Addressable size should be reported as "octets", while address size is reported as "bytes", the later being subject to interpretations. Proposal is to change IGDBMemory.getAddressSize() to report "octets".
Patch for review in https://git.eclipse.org/r/#/c/24849/
(In reply to Teodor Madan from comment #1) > Patch for review in https://git.eclipse.org/r/#/c/24849/ Thanks for posting this update, The change looks good in general although it requires some testing in a target system with minimum addressable size larger than one octet.
(In reply to Alvaro Sanchez-Leon from comment #2) > Thanks for posting this update, > The change looks good in general although it requires some testing in a > target system with minimum addressable size larger than one octet. I could not find a gdb port for such arch. By any chance are you aware of any such port that I could use for smoke testing. Thank you, Teo
> I could not find a gdb port for such arch. By any chance are you aware of > any such port that I could use for smoke testing. > Not really, although I have access to a proprietary system that I could use to test it, I would not be able to go through it now but after a couple of weeks.
(In reply to Teodor Madan from comment #3) > (In reply to Alvaro Sanchez-Leon from comment #2) > > Thanks for posting this update, > > The change looks good in general although it requires some testing in a > > target system with minimum addressable size larger than one octet. > > I could not find a gdb port for such arch. By any chance are you aware of > any such port that I could use for smoke testing. Teodor, I assume that if you noticed the problem which happens on targets with addressable sizes > 1, you may have access to a proprietary target of that kind. Is that not the case? Like Alvaro, I think this change makes sense. But we have to check that all the calls to getAddressSize() expect octets. We really should aim to get that fixed for Luna though.
(In reply to Marc Khouzam from comment #5) > Teodor, I assume that if you noticed the problem which happens on targets > with addressable sizes > 1, you may have access to a proprietary target of > that kind. Is that not the case? I do *not* have access to a gdb port of such proprietary target. The problem in GDB backend was noticed when reviewing Bug 432254 . > Like Alvaro, I think this change makes sense. But we have to check that all > the calls to getAddressSize() expect octets. We really should aim to get > that fixed for Luna though. getAddressSize() is used only through IMemoryBlockExtension#getAddressSize(). Re-reviewing the usage of API confirms experience I had in adding multi-byte addressable support in CDI based debugger backend. After addressing review comments, I would push to head fix for inconsistency in IGDBMemory API. API clarification should be released for 8.4. Alvaro, are you willing to validate the issue later on when you have the time/resources?
(In reply to Teodor Madan from comment #6) > Alvaro, are you willing to validate the issue later on when you have the > time/resources? Yes, I will test it within a couple of weeks.
I've pushed patch to master and will leave open issue for now, until being able to validate. http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=839905a802e6d6562b08cfb9ec5d0513764c1ccd
I have now validated the change, It works as expected using octets instead of addressable units (bytes)
Thank you.
