64-bit pointer masking

[GoogleCodeExporter]

Relatively minor issue.  I've read issues 184 and 190 which discuss the masking 
out the upper 16 bits of 64-bit pointers in the v() and __eq__() functions.  
However this doesn't seem intuitive to me because it is a decision which meets 
halfway between comparing physical values directly in __eq__ and not doing any 
masking at all when comparing virtual addresses.  Also, this comparison is not 
the behavior I would expect when comparing members of a C struct.  I ran into 
issues when comparing with artificially constructed addresses in the form of 
native python integers (see a 64-bit IDT entry for example).  To me, it makes 
most sense to leave detection of aliased virtual addresses up to the specific 
plugin to decide if they care, and only force the masking for purposes of 
calculating vtop of course.  If you buy my argument, I think it makes the most 
sense to also include a member function to do a masked compare (for those 
plugins that want to do it) and then only force the mask when doing vtop.  If 
you don't buy it, then a member function or static utility function to do the 
masking on native python numbers would be nice so the constant 0xffffffffffff 
isn't copied to many places.  Thoughts?

Original issue reported on code.google.com by scorn...@gmail.com on 3 Jan 2013 at 7:11

[GoogleCodeExporter]

Original comment by jamie.l...@gmail.com on 3 Jan 2013 at 3:40

[GoogleCodeExporter]

Hiya, as far as I'm aware, the intention is to remove the pointer masking, and 
require plugins to make use of an explicit pointer comparison function, so that 
it's obvious in the code where it's happening.  We've identified about 8 places 
where it occurs in the current codebase, but unfortunately there hasn't yet 
been the time to get it fixed yet.  Hopefully when we get a few more cycles 
we'll be able to get this sorted, and there should be a single common function 
for carrying out pointer comparisons...

Original comment by mike.auty@gmail.com on 3 Jan 2013 at 8:20

[GoogleCodeExporter]

Yeah, I was going to say the same as mike.auty...we have a drafted patch with a 
function named pointer_compare(a, b) which plugins would use specifically. The 
original v() and __eq__() was a quick fix and turned out to not be exactly what 
we wanted. We should have it fixed in the next few weeks (definitely before 2.3 
release). We'll keep this issue open and let you know - perhaps you can check 
it out and provide feedback since you seem to understand the problem quite well 
;-)

Thanks!

Original comment by michael.hale@gmail.com on 3 Jan 2013 at 10:08

[GoogleCodeExporter]

Original comment by michael.hale@gmail.com on 1 Feb 2013 at 4:12

• Added labels: Milestone-2.3.x

[GoogleCodeExporter]

This issue was closed by revision r3127.

Original comment by michael.hale@gmail.com on 20 Feb 2013 at 2:56

• Changed state: Fixed