I am hitting a problem on syslinux-3.80-pre1-2-g6c0fb9e (only last label in
config file is found),
but don't want to "cry wolf" (again), so let's start with a
question:
ui.inc:
;
; Now check if it is a "virtual kernel"
;
vk_check:
mov esi,[HighMemSize] ; Start from top of memory
.scan:
cmp esi,[VKernelEnd]
jbe .not_vk
mov di,VKernelBuf
call rllunpack
; ESI updated on return
Since "shuffler: make the new shuffler actually work"
(0d8c3d040d9f733f95384f2d5e46609f73bd9c78)
rllunpack in rllpack.inc looks like:
;
; rllunpack:
; Unpack bytes from SI into EDI
; On return (E)SI, EDI are updated and
; (E)CX contains number of bytes output.
;
rllunpack:
push word .pmentry
call simple_pm_call
ret
bits 32
.pmentry:
push edi
movzx esi,si
xor ecx,ecx
It looks to me like rllunpack does trash esi value (upper part), the check at
vk_check.scan succeeds
and we jump to vk_check.not_vk.
In my test i got esi before rllunpack (0x3fece980) and after it's
0x0000e97f.
Am i missing something?
- Sebastian
Sebastian Herbszt wrote:> > ; > ; rllunpack: > ; Unpack bytes from SI into EDI > ; On return (E)SI, EDI are updated and > ; (E)CX contains number of bytes output. > ; > rllunpack: > push word .pmentry > call simple_pm_call > ret > > bits 32 > .pmentry: > push edi > movzx esi,si > xor ecx,ecx > > It looks to me like rllunpack does trash esi value (upper part), the > check at vk_check.scan succeeds > and we jump to vk_check.not_vk. > In my test i got esi before rllunpack (0x3fece980) and after it's > 0x0000e97f. > > Am i missing something? >Count me confused. I wonder how that could ever not have completely screwed over the system! Could you try this patch and see if it works for you (although perhaps the right thing is to make the caller responsible for zero-extending pointers if necessary...)? -hpa -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff URL: <http://www.zytor.com/pipermail/syslinux/attachments/20090427/31753b9a/attachment.ksh>
H. Peter Anvin wrote:> > Count me confused. I wonder how that could ever not have completely > screwed over the system! > > Could you try this patch and see if it works for you (although perhaps > the right thing is to make the caller responsible for zero-extending > pointers if necessary...)? >I just posted a bigger patch doing something more of "the right thing" to the git repo... you may want to test that out instead. -hpa (still confused.)
H. Peter Anvin wrote:> H. Peter Anvin wrote: >> >> Count me confused. I wonder how that could ever not have completely >> screwed over the system! >> >> Could you try this patch and see if it works for you (although perhaps >> the right thing is to make the caller responsible for zero-extending >> pointers if necessary...)? >> > > I just posted a bigger patch doing something more of "the right thing" > to the git repo... you may want to test that out instead.syslinux-3.80-pre1-6-gf2dc4e1 looks good. - Sebastian