Hi, thanks for your response :-)

> Actually, the segment registers look normal for NetBSD purposes (ignore
> the upper bits of what gdb says they are).
>
> I'm not quite sure what gdb disassembles as "jmp ds:XXXXXX". It might
> just be a plain pointer jump, with the pointer being at 0xc0a5d548. What
> is the value at address 0xc0a5d548? What are the bytes in the jmp
> instruction?

I'm not sure how many bytes are in the jump instruction, is this what you
wanted?

(gdb) x/i $pc
0xc0a5d410 <drv_data+252356>:   jmp    ds:0xc0a5d548
(gdb) x/8x $pc
0xc0a5d410 <drv_data+252356>:   0xd54825ff      0x25ffc0a5      0xc0a5d540
     0xd52425ff
0xc0a5d420 <drv_data+252372>:   0x25ffc0a5      0xc0a5d4a4      0x00000000
     0x00000000
(gdb)

Here's everything I can think of to find out what's at that address:

(gdb) x/8i 0xc0a5d548
0xc0a5d548 <drv_data+252668>:   aam    0x7f
0xc0a5d54a <drv_data+252670>:   add    eax,0x0
0xc0a5d54f <drv_data+252675>:   add    BYTE PTR [eax],al
0xc0a5d551 <drv_data+252677>:   add    BYTE PTR [eax],al
0xc0a5d553 <drv_data+252679>:   add    BYTE PTR [eax],al
0xc0a5d555 <drv_data+252681>:   add    BYTE PTR [eax],al
0xc0a5d557 <drv_data+252683>:   add    BYTE PTR [eax],al
0xc0a5d559 <drv_data+252685>:   add    BYTE PTR [eax],al

(gdb) x/8x 0xc0a5d548
0xc0a5d548 <drv_data+252668>:   0x00057fd4      0x00000000      0x00000000
     0x00000000
0xc0a5d558 <drv_data+252684>:   0x00000000      0x00000000      0x420c057d
     0x00000000

Oh, I just noticed that 0x00057fd4 is the same value that's ending up in
the program counter after the jump.  So it must be dereferancing memory at
that address, and jumping there?  Perhaps some initalization code should
have put a valid address here earlier.  Sory to bother you if this is the
case...

Thanks again!