This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> Although I'm not surprised by this behavior, it would be preferable if > the target itself was responsible for managing, inserting and removing > breakpoints. Then a lot of the traffic on the debugging channel could > be avoided. I didn't see anything in the GDB source that suggests > this is possible; but I'm hoping I'm missing something. At Wind River we use GDB with targets that manage their own breakpoints. When I took over maintenance of the local GDB last August, I inherited a fair amount of not-so-clean code sprinked throughout breakpoint.c and our backend, and I don't like the way infrun.c interacts with it. For some reason, wait_for_inferior occasionally wants to pull out all the breakpoints and do something specific, and let them get pushed back in later. This seems to me to never be a good idea. I've already written one "breakpoint management layer" at a previous job. It seems to me that factoring out such a thing would be the correct model for GDB also. However I would prefer to put a single target_manage_breakpoint item in the target vector so that all breakpoint functions are switched at once, rather than exposing lots of little primitives and bloating the target vector struct. Is there an established GDB rule about this sort of thing? At work I now have authorization to rework+submit our local GDB patches, but some accumulated project fires must be put out first and our office is moving during the holidays so I am taking a vacation during that time. So if you don't need this improvement for at least a month or two, then you should just be able to pick up what I submit (assuming I can get it past Stan that is :) ). Todd Whitesel toddpw @ wrs.com