From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Mark Kettenis Cc: dan@cgsoftware.com, gdb@sourceware.cygnus.com Subject: Re: Odd, ptrace_getregs Date: Mon, 13 Mar 2000 23:06:00 -0000 Message-id: <38CDE483.C09982B8@cygnus.com> References: <200003131833.TAA19979@landau.wins.uva.nl> X-SW-Source: 2000-03/msg00228.html Mark Kettenis wrote: > I was silently hoping nobody would notice :-(. I corrected a typo in > configure.in, but forgot to run autoconf before checking it in. It's > basically harmless since it is only the printing of the value that's > broken. I just hoped that someone would find the need to regenerate > configure soon. Feel free to check in a regenerated autoconf. Have a look for the fateful phrase ``Fix typo.'' in the ChangeLogs :-) It should make you feel like you're not alone :-) Andrew >From ac131313@cygnus.com Mon Mar 13 23:46:00 2000 From: Andrew Cagney To: Michael Snyder Cc: dan@cgsoftware.com, Mark Kettenis , gdb@sourceware.cygnus.com Subject: Re: lin-thread cannot handle thread exit Date: Mon, 13 Mar 2000 23:46:00 -0000 Message-id: <38CDEDC5.4107034@cygnus.com> References: <200003031635.e23GZwi00372@delius.kettenis.local> <38C59074.2D7C@cygnus.com> <38C7EDFB.7457@cygnus.com> X-SW-Source: 2000-03/msg00229.html Content-length: 1037 Michael Snyder wrote: > > > All i ever debug on BeOS is multi-threaded apps. > > Almost anything you do involves threads. > > Open a window, you've started at least 2 threads. > > File selection boxes fill in a seperate thread, etc. > > So i constantly have threads coming and going, and doing things. > > The hardest part of the whole port of gdb is telling gdb what > > happened, and making gdb do the right thing. > > On BeOS, we don't even have processes, just teams and threads. > > Everything on BeOS works, except typing run and have it start (you > > have to run and continue) :P. > > I looked at thread_db over the weekend, in hopes of being able to redo > > the port and get it into GDB (it's badly needing a rewrite anyway), > > but it still looks like it has too many problems. > > What problems are you referring to? > Right now the only one I'm aware of is that it doesn't > detect thread exit. Michael, Did you get any further with this? Did the problem exist in the old thread implementation for instance? Andrew >From akale@veritas.com Tue Mar 14 00:17:00 2000 From: "Amit S. Kale" To: gdb@sourceware.cygnus.com Subject: special symbol file address -1: debug lin-kern mods Date: Tue, 14 Mar 2000 00:17:00 -0000 Message-id: <00031413504601.13017@fermat.vxindia.veritas.com> X-SW-Source: 2000-03/msg00230.html Content-length: 1220 Hi, I have been trying to get gdb working at loading linux kernel modules via 'add-symbol-file'. Since it doesn't work properly with gdb, I tried to patch gdb but in vein ( 'regression caused by elfread.c patch' thread ). I had patched gdb 4.18 before I started using current gdb. The patch disabled relocations if symbol file load address was -1. e.g. add-symbol-file foo.reloc -1 loads foo.reloc without relocating. Where foo.reloc is built from linux kernel module foo using ld. ld -o foo.reloc -Ttext< module text address> -Tdata -Tbss -R vmlinux -noinhibit-exec foo How about adding this feature in gdb? Thanks. -- Amit Kale Veritas Software ( http://www.veritas.com ) P.S. Above mentions patch for gdb-4.18 was as follows diff -Naur gdb-4.18/gdb/symfile.c gdb/gdb/symfile.c --- gdb-4.18/gdb/symfile.c Thu Feb 11 05:54:38 1999 +++ gdb/gdb/symfile.c Mon Dec 27 16:15:56 1999 @@ -525,7 +525,7 @@ and assume that is where that got loaded. Due to historical precedent, we warn if that doesn't happen to be a text segment. */ - if (mainline) + if (mainline || addr == -1) { addr = 0; /* No offset from objfile addresses. */ } >From msnyder@cygnus.com Tue Mar 14 10:15:00 2000 From: Michael Snyder To: Andrew Cagney Cc: dan@cgsoftware.com, Mark Kettenis , gdb@sourceware.cygnus.com, drepper@cygnus.com Subject: Re: lin-thread cannot handle thread exit Date: Tue, 14 Mar 2000 10:15:00 -0000 Message-id: <38CE81B2.9CA@cygnus.com> References: <200003031635.e23GZwi00372@delius.kettenis.local> <38C59074.2D7C@cygnus.com> <38C7EDFB.7457@cygnus.com> <38CDEDC5.4107034@cygnus.com> X-SW-Source: 2000-03/msg00231.html Content-length: 1313 Andrew Cagney wrote: > > Michael Snyder wrote: > > > > > > All i ever debug on BeOS is multi-threaded apps. > > > Almost anything you do involves threads. > > > Open a window, you've started at least 2 threads. > > > File selection boxes fill in a seperate thread, etc. > > > So i constantly have threads coming and going, and doing things. > > > The hardest part of the whole port of gdb is telling gdb what > > > happened, and making gdb do the right thing. > > > On BeOS, we don't even have processes, just teams and threads. > > > Everything on BeOS works, except typing run and have it start (you > > > have to run and continue) :P. > > > I looked at thread_db over the weekend, in hopes of being able to redo > > > the port and get it into GDB (it's badly needing a rewrite anyway), > > > but it still looks like it has too many problems. > > > > What problems are you referring to? > > Right now the only one I'm aware of is that it doesn't > > detect thread exit. > > Michael, > > Did you get any further with this? Did the problem exist in the old > thread implementation for instance? > > Andrew As far as I can tell, yes it did. This is something that the thread_db implementation was designed to handle -- I just didn't get around to it. I hope to be able to fit it in "real soon now". >From kingdon@redhat.com Tue Mar 14 11:30:00 2000 From: Jim Kingdon To: gdb@sourceware.cygnus.com Subject: Re: unloading shared objects Date: Tue, 14 Mar 2000 11:30:00 -0000 Message-id: References: <200003131759.SAA07581@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-03/msg00232.html Content-length: 1875 > At present, GDB assumes that we know the shared object's load address > when we read the symbols. Perhaps this is a poor assumption, but it > is pretty fundamental to the current symbol table structure. I'm not > going to fix that as part of this dlclose change. Well, objfile_relocate was written to address this. But I agree, trying to fix this as part of the dlclose fix could be biting off more than is warranted. > - free_objfile calls CLEAR_SOLIB, which isn't what we want, I think. Ouch. That looks really bad. I suspect the CLEAR_SOLIB call can and should be moved up to symbol_file_command (note the call to SOLIB_RESTART - currently vestigial at least on Linux - which relates to the issue of whether to nuke all the shared library symbols on every run of the program). > - Selecting a core file and attaching to a process both add the shared > libraries' sections to the target_ops structure. When we unload a > shared library, we close the BFD those sections refer to. We > need to remove those sections from the target_ops structure. You noticed that one too, eh? ;-). > - Should solib.c be maintaining its own list of shared objects at all, > or should it always retrieve the full link map from the inferior, > and use the objfile list itself as our record of what we know about? Haven't looked at the code long enough to have a really good feel for this, but I think you are probably right. That your changes to nuke find_solib separate out the inferior access code enough to make the above practical. Anyway, thanks for writing this code and let me know if there is anything else I can do (at the moment, various ideas and encouragement seem like a better way for me to help than writing code - not only was my solib.c code somewhat buggy/unpopular, but I didn't really enjoy writing it either :-)). >From jtc@redback.com Tue Mar 14 14:10:00 2000 From: jtc@redback.com (J.T. Conklin) To: Andrew Cagney Cc: GDB Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.) Date: Tue, 14 Mar 2000 14:10:00 -0000 Message-id: <5m8zzl6w5r.fsf@jtc.redbacknetworks.com> References: <200003080845.AAA18410@alabama.wrs.com> <5mitywc5ac.fsf@jtc.redbacknetworks.com> <38C834AD.3379D1F2@cygnus.com> X-SW-Source: 2000-03/msg00233.html Content-length: 1629 >>>>> "Andrew" == Andrew Cagney writes: Andrew> One aspect of this gives me cold feet and sweety palms. Andrew> You're giving the target code access to the entire bp struct. Andrew> While I don't have any problems with handing the code a Andrew> breakpoint handle, I have strong reservations towards any Andrew> moves that give the target unfettered access to the entire Andrew> ``struct breakpoint''. We'll be spending the next 10 years Andrew> trying to get control back again :-) I appreciate this argument, and agree that the target interface should be as robust as possible. After reading your message, I thought about hiding the fact that the argument is a struct breakpoint pointer and providing macros to access "public" fields, but any subversion we do can be undone by a clever programmer. I'm still working on something that is simple, elegant, and efficent. However, I think it's a bit of a stretch to say such changes in and of themselves will lead to GDB being out of control. IMHO, this can only happen if the GDB maintainers fail to do their jobs and integrate code that disrupts GDB's architectural integrity. I'll stipulate that we've done a rather poor job of this in the past, but I'm hopeful that attitudes have changed. Andrew> I'd prefer to see something that tightens rather than loosens Andrew> access to ``struct breakpoint''. Perhaphs something along the Andrew> lines of multi-arch where the target is notified of breakpoint Andrew> create, insert, remove, delete operations. I don't quite follow. Care to elaborate? --jtc -- J.T. Conklin RedBack Networks >From jtc@redback.com Tue Mar 14 14:47:00 2000 From: jtc@redback.com (J.T. Conklin) To: Stephane.Bihan@arccores.com Cc: gdb@sourceware.cygnus.com (GDB) Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.) Date: Tue, 14 Mar 2000 14:47:00 -0000 Message-id: <5m4sa96uf1.fsf@jtc.redbacknetworks.com> References: X-SW-Source: 2000-03/msg00234.html Content-length: 2418 >>>>> "Stephane" == Stephane Bihan writes: jtc> One issue that I'm not sure how to address is that there are several jtc> places breakpoints are inserted where a breakpoint has not been jtc> constructed. Most of these occur in tdep code which implements single jtc> step with breakpoints on processors without a trace mode. Todd> Aiee! Such code is evil and must be destroyed. Stephane> It seems to me that this single_step function is actually Stephane> not in use. I don't know about WindRiver, but here we have Stephane> two targets: an ISS and a remote target that use the generic Stephane> breakpoint functions before stepping. I don't mind to Stephane> remove this code. I assume you are refering to the ARC port? I see three GDB ports that do single step in software: arc, rs6000, and sparc. The arc and sparc ports, insert breakpoints with target- _insert_breakpoint(). The rs6000 port by reading and writing memory directly. Of the two methods, I prefer target_insert_breakpoint(). However, if the breakpoint insert/remove API was changed to require a struct breakpoint pointer, we couldn't call target_insert_breakpoint() in the foo_single_step() functions without creating a real breakpoint object to pass through that first pointer. Another reason we might want a real breakpoint for this is that when my memory region attribute code is complete we'll be able to say that breakpoints in a region should be done with hardware breakpoints. A user can debug his/her own code in read-only memory by using hbreak, but there is no way to tell GDB to use hardware breakpoints for step, next, continue, finish, until, etc. One thing that surprised me was that the single step code used multiple breakpoints. That would put a lot of pressure on hardware breakpoint registers. I suspect that GDB has all the information in order to insert a single breakpoint (by evaluating which way a conditional branch will go, etc.). Since you say you can remove the single step code, I assume that the ISS target and remote protocol agents can perform the single step by themselves? If so, it would be advantageous to disable GDB's single step support. GDB would then issue a single "step" command instead of "insert breakpoint(s)", "continue", and "remove breakpoint(s)". The latency of a step should be greatly improved. --jtc -- J.T. Conklin RedBack Networks >From jtc@redback.com Tue Mar 14 14:56:00 2000 From: jtc@redback.com (J.T. Conklin) To: Todd Whitesel Cc: gdb@sourceware.cygnus.com (GDB) Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.) Date: Tue, 14 Mar 2000 14:56:00 -0000 Message-id: <5mzos15ffa.fsf@jtc.redbacknetworks.com> References: <200003100133.RAA00070@alabama.wrs.com> X-SW-Source: 2000-03/msg00235.html Content-length: 1362 >>>>> "Todd" == Todd Whitesel writes: jtc> One issue that I'm not sure how to address is that there are several jtc> places breakpoints are inserted where a breakpoint has not been jtc> constructed. Most of these occur in tdep code which implements single jtc> step with breakpoints on processors without a trace mode. Todd> Aiee! Such code is evil and must be destroyed. I don't think it's that bad. Todd> One important value of the full breakpoint machinery is that it Todd> can help avoid the same location being patched twice. Any time Todd> we patch the same instruction twice, we must un-patch it in Todd> exactly reverse order or else we leave a breakpoint instruction Todd> sitting in the code -- Not Good. Todd> So I would have to argue that the singlestep logic must either Todd> happen at a really low level (this guarantees it will patch last Todd> and un-patch first) or must go through the real breakpoint logic Todd> which can do duplicate detection. The SOFTWARE_SINGLE_STEP() macro is called at a low enough level that it inserts and remove trap instructions without effecting GDB's high- level breakpoints. So I think we're OK. As a result, I wouldn't be suprised if steping into a breakpoint didn't behave the same as on a machine with hardware single-step. --jtc -- J.T. Conklin RedBack Networks >From jtc@redback.com Tue Mar 14 15:15:00 2000 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com (GDB) Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.) Date: Tue, 14 Mar 2000 15:15:00 -0000 Message-id: <5mvh2p5elj.fsf@jtc.redbacknetworks.com> References: <200003100128.RAA00013@alabama.wrs.com> X-SW-Source: 2000-03/msg00236.html Content-length: 1291 >>>>> "Todd" == Todd Whitesel writes: Andrew> I'd prefer to see something that tightens rather than loosens Andrew> access to ``struct breakpoint''. Perhaphs something along the Andrew> lines of multi-arch where the target is notified of breakpoint Andrew> create, insert, remove, delete operations. Todd> Basically what I need is the moral equivalent of a "user" field Todd> tacked onto every breakpoint struct. Todd> Todd> Based on my existing code, the contents of this field would be: Todd> UINT32 breakpointID; /* WTX-supplied handle for this breakpoint */ Todd> bool is_foreign; /* true if breakpoint was set by someone else */ Todd> bool is_global; /* true if breakpoint active for all tasks */ The reason I was passing the breakpoint pointer (with the intention of adding a "void *private_data" field), is that I don't want to preclude any target implementation. A 32 bit integer ID is probably the most common breakpoint handle, but you never can tell... I don't think your is_foreign flag is suitable for the target specific data, because it changes the behavior of generic breakpoint code. You didn't describe is_global, so I'm not sure about it. How is it different from (bp->thread == -1)? --jtc -- J.T. Conklin RedBack Networks >From toddpw@windriver.com Tue Mar 14 15:31:00 2000 From: Todd Whitesel To: jtc@redback.com Cc: gdb@sourceware.cygnus.com (GDB Developers) Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.) Date: Tue, 14 Mar 2000 15:31:00 -0000 Message-id: <200003142331.PAA18553@alabama.wrs.com> References: <5mvh2p5elj.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-03/msg00237.html Content-length: 1137 > The reason I was passing the breakpoint pointer (with the intention of > adding a "void *private_data" field), is that I don't want to preclude > any target implementation. A 32 bit integer ID is probably the most > common breakpoint handle, but you never can tell... I didn't pretend that this was general enough for everyone, I only said this was what I used. In my case the UINT32 is dictated by the WTX layer that assigns the ID's. > I don't think your is_foreign flag is suitable for the target specific > data, because it changes the behavior of generic breakpoint code. Hmm, actually yeah that's right. It probably should be generic. > You didn't describe is_global, so I'm not sure about it. How is it > different from (bp->thread == -1)? It probably isn't, and is more an artifact of my implementation. The foreign/global stuff was added together, and happened late enough in a development cycle that I needed to keep it isolated and easy to compile back out if we had to cancel it. I had two distinct #ifdef's so I could pinpoint all the changes; I've never taken those out. -- Todd Whitesel toddpw @ windriver.com >From jtc@redback.com Tue Mar 14 15:36:00 2000 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com Subject: memory region attribute CLI Date: Tue, 14 Mar 2000 15:36:00 -0000 Message-id: <5mr9dd5dlt.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-03/msg00238.html Content-length: 1326 I've been told to work on memory region attributes full time, so I expect to make significant progress in the next few days. * create memory region: mem attribute [attribute ...] example: (gdb) mem 0x00008000 0x0000FFFF ro 8 (gdb) mem 0x00007FF0 0x00007FFF rw (gdb) mem 0x00007FE0 0x00007FEF wo 16 (gdb) mem 0x00007FD0 0x00007FDF ro I've followed the behavior of "display" and do not output a message indicating the number of the memory region that has been created. But as I write this message, it seems that it probably should. I think an argument could be made that the same should be done for displays... * enable/disable memory region: enable mem [ ...] disable mem [ ...] example: (gdb) disable mem 2 * delete memory regions: delete mem [ ...] example: (gdb) delete mem 3 * show memory regions: info mem example: (gdb) info mem Num Enb Address Attr 1: y 0x00008000-0x0000FFFF ro, 8 2: n 0x00007FF0-0x00007FFF rw 4: y 0x00007FD0-0x00007FDF ro Thoughts? --jtc -- J.T. Conklin RedBack Networks >From ac131313@cygnus.com Tue Mar 14 16:39:00 2000 From: Andrew Cagney To: Michael Snyder Cc: dan@cgsoftware.com, Mark Kettenis , gdb@sourceware.cygnus.com, drepper@cygnus.com Subject: Re: lin-thread cannot handle thread exit Date: Tue, 14 Mar 2000 16:39:00 -0000 Message-id: <38CEDB3E.DA17FA9A@cygnus.com> References: <200003031635.e23GZwi00372@delius.kettenis.local> <38C59074.2D7C@cygnus.com> <38C7EDFB.7457@cygnus.com> <38CDEDC5.4107034@cygnus.com> <38CE81B2.9CA@cygnus.com> X-SW-Source: 2000-03/msg00239.html Content-length: 427 Michael Snyder wrote: > As far as I can tell, yes it did. > This is something that the thread_db implementation was > designed to handle -- I just didn't get around to it. > I hope to be able to fit it in "real soon now". So this effectivly means that this particular thread problem is a ``nice to have'' rather than a ``must have'' for 5.0. Something that can be better easier fixed in the 5.1 timeframe. enjoy, Andrew >From msnyder@cygnus.com Tue Mar 14 17:01:00 2000 From: Michael Snyder To: Andrew Cagney Cc: dan@cgsoftware.com, Mark Kettenis , gdb@sourceware.cygnus.com, drepper@cygnus.com Subject: Re: lin-thread cannot handle thread exit Date: Tue, 14 Mar 2000 17:01:00 -0000 Message-id: <38CEE0DD.11A@cygnus.com> References: <200003031635.e23GZwi00372@delius.kettenis.local> <38C59074.2D7C@cygnus.com> <38C7EDFB.7457@cygnus.com> <38CDEDC5.4107034@cygnus.com> <38CE81B2.9CA@cygnus.com> <38CEDB3E.DA17FA9A@cygnus.com> X-SW-Source: 2000-03/msg00240.html Content-length: 472 Andrew Cagney wrote: > > Michael Snyder wrote: > > > As far as I can tell, yes it did. > > This is something that the thread_db implementation was > > designed to handle -- I just didn't get around to it. > > I hope to be able to fit it in "real soon now". > > So this effectivly means that this particular thread problem is a ``nice > to have'' rather than a ``must have'' for 5.0. > > Something that can be better easier fixed in the 5.1 timeframe. I would say so. >From huayan_us@yahoo.com Tue Mar 14 18:43:00 2000 From: hua yan To: gdb@sourceware.cygnus.com Cc: insight@sourceware.cygnus.com Subject: how to include iwidgets3.0 Date: Tue, 14 Mar 2000 18:43:00 -0000 Message-id: <20000315024243.24818.qmail@web4002.mail.yahoo.com> X-SW-Source: 2000-03/msg00241.html Content-length: 1981 Dear Consultant: I've written an tcl program using Iwidgets 3.0 's class ---- iwidgets::Fileselectionbox. If run it in Itcl environment that is if I have insalled the Itcl (my O.S is Windows NT 4.0) ,there is no problem.But if I write an C program to startup the Tcl file, some problems will raised. Problem 1: In my C file there have include the following sentences: int Tcl_AppInit(Tcl_Interp *interp) { if (Tcl_Init(interp) != TCL_OK) { return TCL_ERROR; } if (Tk_Init(interp) != TCL_OK) { return TCL_ERROR; } if (Itcl_Init(interp) != TCL_OK) { return TCL_ERROR; } if (Itk_Init(interp) != TCL_OK) { return TCL_ERROR; } return TCL_OK; } In my main.tcl file, there have include the following sentences: package require Tcl 8.0 package require Tk 8.0 package require Itcl 3.0 package require Itk 3.0 package require Iwidgets 3.0 if {![find_iwidgets_library]} { tk_messageBox -title Error -message "Could not find the Iwidgets libraries. Got nameofexec: [info nameofexecutable] Error(s) were: \n$errMsg" \ -icon error -type ok exit } but the error messege "Error: error while autoloading "iwidgets:Fileselectionbox": invalid command name "class"" will appear. Problem 2: In my C file, if call the function "freeconsole()",then in my Tcl, all places including {open "|..."} being executed, can not launch the program,error message "Error: couldn't duplicate input handle:bad file number" will appear. if not call the "freeconsole",then behind my main interface there is always an blank screen, but can launch the program. problem 3: if startup the program from C file, then my main menu will display some curious characters if the original character is chinese. best wishes huayan 2000-3-15 __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com >From fedor@doc.com Tue Mar 14 19:54:00 2000 From: Adam Fedor To: gdb@sourceware.cygnus.com Subject: Objective-C patches? Date: Tue, 14 Mar 2000 19:54:00 -0000 Message-id: <38CF0958.DCEDD532@doc.com> X-SW-Source: 2000-03/msg00242.html Content-length: 473 I read a rather cryptic remark on the list a while back that indicated that the Objective-C patches from Apple/NeXT would be integrated into GDB soon (maybe by 5.1?). Is this true or are the patches still languishing? Is a volunteer necessary for getting this going? -- Adam Fedor, Digital Optics | Fudd's law of opposition: Push fedor@doc.com ( http://www.doc.com ) | something hard enough, and it will fedor@gnu.org ( http://www.gnustep.org )| fall over. >From Stephane.Bihan@arccores.com Wed Mar 15 04:21:00 2000 From: Stephane.Bihan@arccores.com To: jtc@redback.com Cc: Yuri Karlsbrun , gdb@sourceware.cygnus.com Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.) Date: Wed, 15 Mar 2000 04:21:00 -0000 Message-id: X-SW-Source: 2000-03/msg00243.html Content-length: 3416 > >>>>> "Stephane" == Stephane Bihan writes: > > jtc> One issue that I'm not sure how to address is that there are several > jtc> places breakpoints are inserted where a breakpoint has not been > jtc> constructed. Most of these occur in tdep code which implements single > jtc> step with breakpoints on processors without a trace mode. > > Todd> Aiee! Such code is evil and must be destroyed. > > Stephane> It seems to me that this single_step function is actually > Stephane> not in use. I don't know about WindRiver, but here we have > Stephane> two targets: an ISS and a remote target that use the generic > Stephane> breakpoint functions before stepping. I don't mind to > Stephane> remove this code. > > I assume you are refering to the ARC port? yes. But I was actually wrong in my last email, the single step function in arc-tdep is used, I was thinking to another function, sorry. What do you mean by breakpoint without a trace mode? > > I see three GDB ports that do single step in software: arc, rs6000, > and sparc. The arc and sparc ports, insert breakpoints with target- > _insert_breakpoint(). The rs6000 port by reading and writing memory > directly. Of the two methods, I prefer target_insert_breakpoint(). > > However, if the breakpoint insert/remove API was changed to require a > struct breakpoint pointer, we couldn't call target_insert_breakpoint() > in the foo_single_step() functions without creating a real breakpoint > object to pass through that first pointer. I don't know what are the foo_single_step functions. I also use the breakpoint structure as an extern variable. I needed it to implement the set_hw_breakpoint routine for the remote protocol. I think it's not the nicer way to do but .... > Another reason we might want a real breakpoint for this is that when > my memory region attribute code is complete we'll be able to say that > breakpoints in a region should be done with hardware breakpoints. > A user can debug his/her own code in read-only memory by using hbreak, > but there is no way to tell GDB to use hardware breakpoints for step, > next, continue, finish, until, etc. One thing that surprised me was > that the single step code used multiple breakpoints. That would put a > lot of pressure on hardware breakpoint registers. I suspect that GDB > has all the information in order to insert a single breakpoint (by > evaluating which way a conditional branch will go, etc.). > What would be a "real breakpoint"? a pointer to the breakpoint structure? > > Since you say you can remove the single step code, I assume that the > ISS target and remote protocol agents can perform the single step by > themselves? If so, it would be advantageous to disable GDB's single > step support. GDB would then issue a single "step" command instead of > "insert breakpoint(s)", "continue", and "remove breakpoint(s)". The > latency of a step should be greatly improved. I will implement this for the remote target only since the hardware supports single-stepping. I'm not sure if this feasible in the ISS - Yuri? If not feasible I won't disable the GDB's single step support (thus enabling a call to single_step()) but I will implement a single_step call to gdbstub in remote_resume(). Stephane. ---------------------------------------------------------------- Stephane Bihan ARC Cores Ltd http://www.arccores.com