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. There are several parts in QEMU that use cpu_memory_rw_debug for reading or writing code segment: the disassembler, KVM when manipulating soft breakpoints, and also the TB flushing on breakpoint changes relies on cpu_get_phys_page_debug and would break when using DS as base. > correctly and exclusively use CS.base. However, any memory examination > uses DS.base, and you're right that the user might "want" to examine > some other segment. A GDB fix would involve changing the gdb remote > protocol as well as GDB itself and the GDB user interface. Google says > you've been thinking about that for a while now -- is it going well? It's on a long list of things that would be nice to work on... > >> For the time being, you should be able to workaround the gdb limitation >> by setting two breakpoints: one on the linear address and another one on >> the CS offset. Not nice, but used to work for us. > > I don't mind the double-breakpoint as much, but memory examination would > still be broken, yes? Issue "monitor info registers", extract the segment base, add it to the variable address you are interested in, and issue a print request. It is definitely not impossible, just "a bit" unhandy. > > I don't understand the comment about "prevents setting breakpoints on > inactive segments." The code for setting breakpoints has not changed. It has because you unconditionally subtract the CS base from the passed address. If you want to set a breakpoint on some other CS, you would have to account for their base offsets and pass a weirdly "corrected" address from gdb. That's really no sane interface, specifically long-term. > > Do you think the patch would actually make debugging WORSE on any OS? Or > have any other undesirable effects, or make it harder to DTRT when GDB > is ready? It seems safe & useful to me; & it's 2 LOC! The pathes change the interface to gdb by re-defining the semantics of the passed addresses in way that is not future-proof, and they are buggy. Jan
signature.asc
Description: OpenPGP digital signature
