Subject: Re: Problem with uvm and AcceleratedX
To: None <Havard.Eidnes@runit.sintef.no>
From: Dave Huang <khym@bga.com>
List: port-i386
Date: 04/08/1998 10:40:53
On Tue, 7 Apr 1998 Havard.Eidnes@runit.sintef.no wrote:
> And what version does that apply to?  If I go to byte 0x4a8b (19083)
> of my Xaccel version 3.1 binary, I appear to end up somewhere in the
> middle of a string table in some symbol table of the executable.
> Could you please tell me how you found the offending byte?  My gdb
> does not know how to handle a FreeBSD/i386 executable.
> 
> The string "/dev/mem" first occurs at position 51265 of my
> executable.

Here's an idea... I don't know if it'll actually work, but it's worth a
try :) First find where the string "/dev/mem" occurs in the exe (which
you've already done :) In my example, I'm using the FreeBSD 4.1 demo
server:

% strings -t x Xaccel | grep /dev/mem
000e800 /dev/mem
000e809 Couldn't open "/dev/mem"

On the i386, a.out binaries are apparently loaded at 0x1000. So, 0xe800
in the file would end up at 0xf800 in memory. Use objdump or some other
disassembler to see where 0xf800 is referenced. For some reason, objdump
doesn't get the load address correct for FreeBSD binaries; it assumes
the text segment ends up at address 0. You can use the --adjust-vma
option to fix this though. (0x1020 because the a.out exec header is 0x20
bytes long and the text segment seems to always come right after that.
Also, see bytes 0x14 through 0x17 of the executable)

% objdump -d --adjust-vma=0x1020 Xaccel > Xaccel.s
% grep -n 0xf800 Xaccel.s
24579:    f844: 68 00 f8 00 00  pushl  $0xf800
233741:   8c127:        00 a1 00 00 00  addb   %ah,0xf8000000(%ecx)
239214:   8f26b:        00 05 02 00 00  addb   %al,0xf8000002

So, it's only referenced at one place... take a look around there...

% less +24574 Xaccel.s
    f838:       53              pushl  %ebx
    f839:       83 3d dc f3 09  cmpl   $0xffffffff,0x9f3dc
    f83e:       00 ff 
    f840:       75 2e           jne    f870
    f842:       6a 00           pushl  $0x0
    f844:       68 00 f8 00 00  pushl  $0xf800
    f849:       e8 3e d9 08 00  call   9d18c
    f84e:       a3 dc f3 09 00  movl   %eax,0x9f3dc
    f853:       83 c4 08        addl   $0x8,%esp
    f856:       83 f8 ff        cmpl   $0xffffffff,%eax
    f859:       75 15           jne    f870
    f85b:       68 09 f8 00 00  pushl  $0xf809
    f860:       e8 4b 20 04 00  call   518b0
 
That looks like the one to me... f842 pushes the flags to the open call
(O_RDONLY), f844 pushes the pointer to the pathname ("/dev/mem"), and
f849 calls open(). Also, if you look a bit after that, you can see that
if the call returns -1, it pushes 0xf809, the address of the "Couldn't
open "/dev/mem"" message and calls some routine... maybe perror() or
something. Anyways, you want to change the "pushl $0x0" to "pushl $0x2",
so for the Xaccel 4.1 demo, you'd change byte 0xe843 of the binary from
0 to 2.

At least that's the theory... I haven't actually tried patching/running
the 4.1 demo server. Good luck! :)
-- 
Name: Dave Huang     |   Mammal, mammal / their names are called /
INet: khym@bga.com   |   they raise a paw / the bat, the cat /
FurryMUCK: Dahan     |   dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 22 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++