|
From: Roland M. <ro...@re...> - 2004-12-04 02:31:09
|
> Segments are a bit trickier, because Valgrind takes short-cuts. As I said, in practice these assumptions are valid for what interesting guest kernels actually do. If you do want to cope with it, it's a) not hard to identify the case, and b) not all that complex to support. That is, when you hit a segment register load instruction or an intersegment jump/call instruction, stop the world, possibly throw away all your cached translations, and switch to the slower plan where the translated code does the segmented->linear translation work. I said it's not too complex to support, but that doesn't mean it wouldn't be slow. That's why it's a feature to support on demand that will never be demanded. Even the current hardware presumes flat segmentation will be used and, relatively speaking, is dog slow if a kernel tries to use it any other way. > Valgrind maintains a cache of translated code, which is indexed by eip; > like segments for data access, cs is assumed to be flat and unchanging. > If cs changes around, we'd need to make sure that the translation cache > is maintained appropriately. You just want the translation cache to remain in terms of linear eip values, and apply segmentation transformations to virtual CPU eip values before going to the code translation step. > One wart is that the mode of the CPU (16/32/64?) is a property of the > current cs, and that affects how the instruction bytes are actually > interpreted; if we wanted to support the different sizing modes, we'd > need to make sure that we maintain the translation cache properly. This is another thing that is straightforward and that in practice probably noone will ever ask us to do. That is, 16-bit mode. If we have a pure-virtual valgrind for xen/x86-64, it should support going into 32-bit user mode. Keeping the translations straight is simple; you just need to include some mode bits from the segmentation universe along with the linear address in what constitutes the lhs of the translation cache. More of the work is making the translator understand the 64-bit (16-bit) instruction set you get in 64-bit mode. > At least changes to cs are pretty obvious; when translating any kind of > trap/long jump/call/ret we generate code to observe how cs is changed. All segment register moves are as easily noted in translation. Anyway, this is pretty much hypothetical. There is no call to support code that makes use of segmentation much, because none around does. It's sufficient to have checks on segment register changes (rare, easily-identified instructions) and punt in flames when any happen that might mean something. Thanks, Roland |