|
From: Samuel B. <na...@gm...> - 2009-06-26 03:22:51
|
Ping?
At Wed, 24 Jun 2009 20:08:32 -0400,
Samuel Bronson <na...@gm...> wrote:
>
> Hi. I'm trying to run some DPMI code under DOSEMU under valgrind,
> hoping to track down some sort of leak, but valgrind gets stuck on
> some of the segmentation-related instructions. For example, trying to
> run DJGPP's ls, I get this:
>
> ,----
> | 0x473600D: lss (%esp,,),%esp
> |
> | ------ IMark(0x473600D, 4) ------
> | PUT(60) = 0x473600D:I32
> | t14 = GET:I32(16)
> | PUT(16) = LDle:I32(t14)
> | PUT(290) = LDle:I16(Add32(t14,0x4:I32))
> |
> | 0x4736011: vex x86->IR: unhandled instruction bytes: 0x2E 0xFF 0x2D 0x0
> | ------ IMark(0x4736011, 0) ------
> | PUT(60) = 0x4736011:I32
> | PUT(60) = 0x4736011:I32
> | goto {NoDecode} 0x4736011:I32
> |
> | . 0 4736000 17
> | . 89 D4 0F A9 0F A1 07 1F 61 83 C4 10 9D 0F B2 24 24
> |
> | ==13075== Warning: client switching stacks? SP change: 0xbed3e730 --> 0x821dba0
> | ==13075== to suppress, use: --max-stackframe=1229845616 or greater
> | ==13075== Warning: client switching stacks? SP change: 0x821dbe4 --> 0x760
> | ==13075== to suppress, use: --max-stackframe=136434820 or greater
> | ==13075== valgrind: Unrecognised instruction at address 0x4736011.
> | ==13075== Your program just tried to execute an instruction that Valgrind
> | ==13075== did not recognise. There are two possible reasons for this.
> | ==13075== 1. Your program has a bug and erroneously jumped to a non-code
> | ==13075== location. If you are running Memcheck and you just saw a
> | ==13075== warning about a bad jump, it's probably your program's fault.
> | ==13075== 2. The instruction is legitimate but Valgrind doesn't handle it,
> | ==13075== i.e. it's Valgrind's fault. If you think this is the case or
> | ==13075== you are not sure, please let us know and we'll try to fix it.
> | ==13075== Either way, Valgrind will now raise a SIGILL signal which will
> | ==13075== probably kill your program.
> `----
>
> -- and that's AFTER adding support for the LSS instruction to VEX.
>
> It turns out that the unrecognized instruction is some kind of
> indirect far jump that ndisasm renders as:
>
> 00000000 2EFF2D00010203 jmp dword far [dword cs:0x3020100]
>
> and objdump as:
>
> 0: 2e ff 2d 00 01 02 03 ljmp *%cs:0x3020100
>
> (the address part is mostly bogus since I'm just working with the four
> bytes that VEX dumped for me, but that shouldn't matter.)
>
> It does not look as if either VEX or valgrind supports having CS refer
> to a non-flat segment; how crazy would it be to try to add this?
>
> P.S. The code for LSS should be in
> https://code.launchpad.net/~naesten/valgrind/vex-segmented soon; it's
> not there quite yet on account of having to push the entire SVN trunk
> history of vex, which is taking a bit -- it's been almost ten minutes
> already, and the progress bar looks to be at about 50%, though I have
> my doubts as to whether or not it means anything.
|