On Fri, Nov 10, 2006 at 08:01:54PM +0100, Marcel Kilgus wrote:
> Or do you mean that qemu should always and in all situations report an
> adjusted EIP to GDB and re-adjust all EIPs it gets? Interesting idea,
> but I guess that too would lead to dozens of other problems.
Yes precisely. I doubt it
Daniel Jacobowitz wrote:
> I'd recommend the even simpler hack of having qemu report a PC that
> included the segment base :-)
Probably sounds easier than it is, as seen the serial protocol doesn't
include the PC when a breakpoint fires. qemu would have to
intentionally report a wrong EIP the next
On Fri, Nov 10, 2006 at 03:56:01PM +, Paul Brook wrote:
> > Assuming that breakpoint locations are indeed meant to be virtual
> > addresses, GDB would have to evaluate the CS descriptor, add the CS
> > base to the EIP address and THEN check whether it knows the address.
> > But as it seems to b
Paul Brook wrote:
> As Dan said, gdb knows nothing about x86 segmentation. As soon as you have
> nonzero segment bases you're pretty much on your own.
I was just wondering, because I didn't invent that "move the code to
3GB base" but it is (was?) the model used by Linux, at least in very
early ver
> Assuming that breakpoint locations are indeed meant to be virtual
> addresses, GDB would have to evaluate the CS descriptor, add the CS
> base to the EIP address and THEN check whether it knows the address.
> But as it seems to be segment-agnostic it doesn't do that and things
> break as a result
andrzej zaborowski wrote:
>> Well, that explains it then, I guess. In that case I don't really see
>> a clean solution for it.
> If I understand the problem, the clean solution is having the
> debugging symbols at the right addresses: in code that runs with
> paging enabled symbols should be at the
On 08/11/06, Marcel Kilgus <[EMAIL PROTECTED]> wrote:
> Correct. It doesn't know anything at all about i386 segmentation.
Well, that explains it then, I guess. In that case I don't really see
a clean solution for it.
If I understand the problem, the clean solution is having the
debugging symb
On Thu, Nov 09, 2006 at 12:57:29AM +0100, Marcel Kilgus wrote:
> Daniel Jacobowitz wrote:
> >> Leaving that aside, if I do set the breakpoint correctly at virtual
> >> address (e.g.) 0xC0123456 qemu will (correctly I guess) cause an
> >> exception for code offset 0x123456 (as CS base is 0xC000)
Daniel Jacobowitz wrote:
>> Leaving that aside, if I do set the breakpoint correctly at virtual
>> address (e.g.) 0xC0123456 qemu will (correctly I guess) cause an
>> exception for code offset 0x123456 (as CS base is 0xC000). GDB
>> however then doesn't recognize its own breakpoint as it only r
On Thu, Nov 09, 2006 at 12:33:05AM +0100, Marcel Kilgus wrote:
> Leaving that aside, if I do set the breakpoint correctly at virtual
> address (e.g.) 0xC0123456 qemu will (correctly I guess) cause an
> exception for code offset 0x123456 (as CS base is 0xC000). GDB
> however then doesn't recogni
Fabrice Bellard wrote:
> The breakpoints are set for a given virtual address. So IMHO testing
> only the EIP value instead of EIP + CS.base is not logical...
That I just check for EIP is a convenience for me. The code is linked
to 0x0010 but moves itself to the virtual address 0xC010 (CS
s
Marcel Kilgus wrote:
/me wrote:
Having to always set them both in the high and low area is a bit
cumbersome to say the least. Any suggestion on what I'm missing or can
do to get breakpoints working properly again?
Okay, the QEMU source code was a lot more readable than I expected it
to be, s
/me wrote:
> Having to always set them both in the high and low area is a bit
> cumbersome to say the least. Any suggestion on what I'm missing or can
> do to get breakpoints working properly again?
Okay, the QEMU source code was a lot more readable than I expected it
to be, so I had a look myself
13 matches
Mail list logo
