qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ideas to Improve GDB Stub in Qemu for i8086


From: Bernhard Beschow
Subject: Re: Ideas to Improve GDB Stub in Qemu for i8086
Date: Fri, 20 Dec 2024 11:14:46 +0000


Am 20. Dezember 2024 00:34:26 UTC schrieb Davidson Francis 
<davidsondfgl@gmail.com>:
>On Thu, Dec 19, 2024 at 09:51:13AM -0700, Warner Losh wrote:
>> I might be interested in debugging some i8086 stuff for my Venix/86
>> emulation
>> project.
>> 
>> I'm curious, though. I see special cases just for EIP being returned as (CS
>> << 4):EIP
>> and similar for ESP being just (SS << 4):SP. What does the debugger do,
>> though,
>> for other cases where you need segment:offset addresses? Does it translate
>> properly
>> behind the scenes in ways it doesn't do for ESP/EIP or do you have to
>> examine those
>> addresses by hand as well? If I'm chasing a linked list with 16-bit
>> addresses that assume
>> a particular DS, how does that work?
>>
>
>You've brought up a very interesting point. Indeed, in the case of 
>linked lists and similar structures, there’s no way for GDB or QEMU to 
>reliably determine which segment an address might belong to—perhaps 
>only guesses, which are far from ideal.  
>
>That said, the approach I'm proposing doesn’t solve all problems and 
>still requires users to handle these conversions manually or through GDB 
>scripts.  
>
>The main goal of my idea is simply to reduce the initial effort required 
>to debug i8086 code, avoiding workarounds with architecture XML files, 
>and proper instruction disassembly and stack dumps out-of-the-box.

I suggest to submit a patch with a descriptive commit message to see where it 
is going. To me, your changes seem reasonable and I could have benefited from 
them already in my VIA Apollo Pro 133T project [1] where I made some real-world 
bioses run in QEMU.

Best regards,
Bernhard

[1] https://github.com/shentok/qemu/tree/via-apollo-pro-133t

>
>Kind regards,
>Davidson Francis.
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]