|
From: John R.
|
Julian Seward wrote: > Fine, but how can it be that this Allegro library is using GDT > entries in a meaningful way if it doesn't have any way to > somehow specify the contents of the GDT entry it is using? It seems to me that this "Allegro" package, being an environment for "video arcade" games, might be manipulating the hardware directly. In particular, the VGA hardware as "borrowed" from X11. The segment register(s) probably designate the VGA physical video memory. From http://alleg.sourceforge.net/wip.html I downloaded and built allegro-4.2.0.tar.gz which is not the same version as the original poster in this thread. I ran it and clicked a few default responses, then it started running a full-screen "teaser" to get me to deposit my $0.25 coin [;-)] and start playing the game. <ESC> got me out. Under valgrind-3.1.1, I see: ----- $ valgrind --db-attach=yes ./demo ==20077== Memcheck, a memory error detector. ==20077== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==20077== Using LibVEX rev 1575, a library for dynamic binary translation. ==20077== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==20077== Using valgrind-3.1.1, a dynamic binary instrumentation framework. ==20077== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==20077== For more details, rerun with: -v ==20077== vex x86->IR: unhandled instruction bytes: 0x66 0x6 0x8B 0x55 ==20077== Your program just tried to execute an instruction that Valgrind ==20077== did not recognise. There are two possible reasons for this. ==20077== 1. Your program has a bug and erroneously jumped to a non-code ==20077== location. If you are running Memcheck and you just saw a ==20077== warning about a bad jump, it's probably your program's fault. ==20077== 2. The instruction is legitimate but Valgrind doesn't handle it, ==20077== i.e. it's Valgrind's fault. If you think this is the case or ==20077== you are not sure, please let us know. ==20077== Either way, Valgrind will now raise a SIGILL signal which will ==20077== probably kill your program. Shutting down Allegro due to signal #4 not in syscall (0xB0041A30 - 0xB0041A85) ==20077== ==20077== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y ==20077== starting debugger with cmd: /usr/bin/gdb -nw /proc/20081/fd/1014 20081 [snip] Attaching to program: /proc/20081/fd/1014, process 20081 Reading symbols from shared object read from target memory...(no debugging symbols found)...done. Loaded system supplied DSO at 0x602000 `shared object read from target memory' has disappeared; keeping its symbols. 0xb001b7c1 in ?? () (gdb) info reg eax 0x0 0x0 ecx 0x4e6d 0x4e6d edx 0x4 0x4 ebx 0x4e6d 0x4e6d esp 0xbe891f1c 0xbe891f1c ebp 0xbe891f2c 0xbe891f2c esi 0x4 0x4 edi 0xdccff4 0xdccff4 eip 0xb001b7c1 0xb001b7c1 eflags 0x200202 0x200202 cs 0x73 0x73 ss 0x7b 0x7b ds 0x7b 0x7b es 0x0 0x0 fs 0x0 0x0 gs 0x621c0003 0x621c0003 (gdb) ----- So, on to debugging: 1. WHAT THE !@#$% IS THE VALUE OF THE PC where the unhandled bytes reside? This ESSENTIAL piece of information is nowhere to be found! I'd like to look at the instruction stream just before and after, identify which module (main or shared library) is responsible, etc. 2. Assuming that the bytes "0x66 0x6 0x8b 0x55" really are the instruction stream, then the instruction is "pushw %es". From "(gdb) info reg" %es is 0, the initial value. So the code isn't banging the hardware yet. 3. I tracked down a plausible module by: (gdb) info proc (gdb) shell cat /proc/<pid>/maps $ for i in $(cat mapped-module-pathnames) > do echo $i; objdump --disassemble $i | grep "06 8e"; done which reveals that ./demo contains 08056098 <_linear_putpixel16>: 8056098: 55 push %ebp 8056099: 89 e5 mov %esp,%ebp 805609b: 53 push %ebx 805609c: 66 06 pushw %es 805609e: 8b 55 08 mov 0x8(%ebp),%edx Clearly this is saving state in order to muck with the VGA hardware. This routine, or some subroutine, will set %es to a descriptor which maps VGA memory, modify that [video] memory [and hence the display], then restore %es upon exit. So the first answer is that it is the VGA *physical* memory segment. There are three of them: 64KB from 0xA0000-0xAFFFF for color graphics, 32KB from 0xB8000-0xBFFFF for color text, and 32KB from 0xB0000-0xB7FFF for monochrome text. The color graphics is bank-switched (eight 64KB banks) using control registers which appear in I/O space. Each bank is a single bitplane. To write a single 8-bit pixel requires changing the bank register 8 times, although obviously writing adjacent pixels is done so as to require switching banks only 8 times total instead of 8 times for each pixel. -- |