Am 26.09.2010 19:19, Eddie Kohler wrote:
> OK, thanks. I understand how you're relying on the current behavior.
>
> I'd rather not change all of QEMU and GDB in one step,
The first step is changing gdb anyway.
> but I'd like to
> address this. QEMU documentation implies, and new users expect,
OK, thanks. I understand how you're relying on the current behavior.
I'd rather not change all of QEMU and GDB in one step, but I'd like to
address this. QEMU documentation implies, and new users expect, that
debugging uses virtual addresses, not the segmentation-specific "linear
addresses"
Am 25.09.2010 10:35, Eddie Kohler wrote:
> Thanks for the response. I agree the patch is a workaround, but it is a
> useful workaround, and I'd still argue for including it.
Nope, sorry, I have to vote against this.
>
> The patch doesn't *require* that CS.base == DS.base. Breakpoints
It does.
Thanks for the response. I agree the patch is a workaround, but it is a
useful workaround, and I'd still argue for including it.
The patch doesn't *require* that CS.base == DS.base. Breakpoints
correctly and exclusively use CS.base. However, any memory examination
uses DS.base, and you're r
Am 25.09.2010 02:25, Eddie Kohler wrote:
> Hi,
>
> QEMU has a bug that complicates GDB debugging of i386 targets when the
> current code or data segment has a nonzero base. A fix is attached.
>
> If the current code segment has a nonzero base, breakpoints don't work
> as expected, because the br