From mboxrd@z Thu Jan 1 00:00:00 1970 From: fche@redhat.com (Frank Ch. Eigler) To: nsd@redhat.com (Nick Duffek) Cc: cagney@redhat.com, jtc@redback.com, sid@sources.redhat.com, gdb-patches@cygnus.com Subject: Re: Possible remote.c patch for Z-packet breakpoints + Harvard + SID Date: Mon, 16 Jul 2001 15:05:00 -0000 Message-id: References: <200107161931.f6GJVV719853.cygnus.project.sid@rtl.cygnus.com> X-SW-Source: 2001-q3/msg00015.html nsd wrote: : [...] : I see your point, though I think it's debatable. For one thing, Z-packet : breakpoints are tagged as "Z_PACKET_SOFTWARE_BP" in gdb/remote.c, so it : looks like they're intended to be a generic protocol speedup rather than a : hardware breakpoint mechanism. : [...] That's true - it makes me rethink my earlier point. : I proposed a patch in January to call BREAKPOINT_FROM_PC() before rather : than after remote.c stores hardware breakpoint addresses in outgoing : packets, but it was decided that such a change should be at a higher : level, e.g. in target_insert_breakpoint(). : : This problem can't be fixed in target_insert_breakpoint(), because the : distinction between "hardware" (Z-packet) and software breakpoints is made : in remote.c. : [...] If this gdb-side approach is not deemed acceptable to gdb folks, we may be able to make complementary changes on the sid side without too much littering. One possibility: map hardware breakpoints to mask/value-type sid "triggerpoints" on the PC register instead of plain value-type ones; parametrize the gdb-interface-component with the desired mask for a target. This sort of thing may be useful for PC-range breakpoints too. - FChE