Mail Archives: djgpp-workers/2002/05/19/16:06:03
> > the lcall is a fairly small (it's in sbrk16.asm) and does the following:
>
> Is there any way I could use gdb in that code or should I use other
> means to see where it fails?
I don't know of a way to debug the 16-bit PM code called from DJGPP.
My debugging of these things was typically done under OS/2 - which did
an excellent job of printing out everything if a failure happened.
Since I haven't had a working OS/2 system in about 7 or 8 years ...
> > 3) resets the base of cs and ds selectors (note: ds alias's base is not
> > changed until several hundred instructions later, so there is a
> > short term inconsistency - which might cause problems - any exception
> > at this point would probably kill ntvdm).
>
> You mean this piece?
>
> 3:
> movw $0x0007, %ax /* reset DS alias base */
> movl ___djgpp_ds_alias, %ebx
> movl ___djgpp_base_address, %edx
> movw ___djgpp_base_address+2, %cx
> int $0x31
Yes, that's the one. If we had the ds_alias passed into the 16-bit
helper, it would be a matter of adding:
mov bx, [ds_alias]
mov ax, 0x0007
int 0x31
Since the base is already loaded into cx:dx. We could use a register
like bp or dx also (currently not used in interface).
> Well, it seems like it shouldn't be too hard to move to sbrk16.asm.
> But I think it is better to find out real causes for failures first.
I'll try to write a little test program and see if I can make a simple
example fail under Win2K. If so, it will be much easier to debug. If
not, then we know it's something special emacs does.
- Raw text -