From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: john@Calva.COM Cc: gdb-patches@sources.redhat.com Subject: Re: Patch for gdb5.0; enable hardware watchpoints on UnixWare Date: Tue, 31 Oct 2000 09:10:00 -0000 Message-id: <200010311710.MAA22110@indy.delorie.com> References: X-SW-Source: 2000-10/msg00300.html > From: "John Hughes" > Date: Tue, 31 Oct 2000 15:30:23 +0100 > > > I _will_ try to make the generic code general enough to be easily > > usable by all targets which already have watchpoint support. > > What will you need? A macro to get the debug registers for a pid > and one to put 'em back? No, I think that's too tailored to some targets and won't work for some of the others. I think we need functions to pass the debug registers between GDB and the system-dependent interface between the debugger and the debuggee. For example, i386v-nat.c uses ptrace, but go32-nat.c doesn't. (In fact, if you look at go32-nat.c, you probably won't understand how the heck do the debug register wind up in the debuggee, because the code to do that is not in GDB's sources, it's in a special library supplied with DJGPP.) > > > 1. Why not zap the waddr arg to go32_..._watchpoint? It's not used. > > > > It might be there because GDB needs that argument for some other > > (non-x86) target. > > It isn't. Yes, you are right. waddr is a left-over from i386v-nat.c, which is where the go32-nat.c code originated. Thanks for pointing this out. > > > 2. In go32_insert_aligned_watchpoint... > > > > I think you are looking at an old version of go32-nat.c. > > My comments refer to the version labeled '1.6' in the cvsweb. Is there > a later one I could look at? That's the latest version. Hmm... Oh, I see what happened: you were talking about go32_insert_aligned_watchpoint, whereas I was looking at go32_remove_aligned_watchpoint (because you said that it has the same problems). Sorry about that misunderstanding. Yeah, okay, I think you are right, and the code could be made simpler. Thanks for pointing that out. (That code was written by several people over several years, and it shows.) > > While I generalize the code, I will bring it up to date with the letter > > of Intel's manuals. > > So you're going to have your own defines for DR_... and not use the > system ones? I guess that was why your code didn't match up to what > I find in sys/debugreg.h on my system. I was unaware of sys/debugreg.h until now. Is it present on all Unix x86-based systems? If not, we will need some configury magic to handle this. DJGPP certainly doesn't have sys/debugreg.h, and I don't know how about Cygwin. What do people think about relative merits of using sys/debugreg.h vs having the definitions inside GDB (or both)? >From larry@smith-house.org Tue Oct 31 09:19:00 2000 From: Larry Smith To: Fernando Nasser Cc: gdb-patches@sources.redhat.com, insight@sources.redhat.com Subject: Re: [RFA] 100494 fix Date: Tue, 31 Oct 2000 09:19:00 -0000 Message-id: <39FEFF6D.57CC24A0@smith-house.org> References: <200010272126.RAA02584@ozma.smith-house.org> <39FDDFB0.D995A63E@cygnus.com> X-SW-Source: 2000-10/msg00301.html Content-length: 5283 Fernando Nasser wrote: > > Good catch Larry. But please add a labeled frame around the radiobuttons, > will you? The target selection dialog expansion box does look weird with > two square buttons and two rounds with no explanation. > > "Run method" sounds right for the frame label. > > If you really want to fix this, make sure the option is set to "run" and > the buttons greyed if the target "exec" is selected. Okay, this is a bit more involved than the previous patch, but it seems to do what Fernando wants. It adds a new var to the header file to save the pathnames for the run method buttons, and when the target selection is changed to "exec", these buttons are greyed out (and "run" selected) and when it is anything else, the buttons are active and set to what- ever the program would have set them to. This has NOT been checked in or committed. Permission to do so? > cvs diff -r 1.2 targetselection.ith Index: targetselection.ith =================================================================== RCS file: /cvs/src/src/gdb/gdbtk/library/targetselection.ith,v retrieving revision 1.2 diff -r1.2 targetselection.ith 57a58,59 > > variable run_method > > cvs diff -r 1.5 targetselection.itb Index: targetselection.itb =================================================================== RCS file: /cvs/src/src/gdb/gdbtk/library/targetselection.itb,v retrieving revision 1.5 diff -r1.5 targetselection.itb 489a490,493 > set rm_frame [iwidgets::labeledframe $frame.run_method -labelpos nw -labeltext "Run Method" ] > set run_method [ $rm_frame childsite ] > > set rm_label [label $frame.label -text "Run Method:"] 491c495 < radiobutton $frame.cont -text {Continue from Last Stop} -value 1 -variable $var \ --- > radiobutton $run_method.cont -text {Continue from Last Stop} -value 1 -variable $var \ 495c499 < radiobutton $frame.run -text {Run Program} -value 1 -variable $var \ --- > radiobutton $run_method.run -text {Run Program} -value 1 -variable $var \ 501,504c505,516 < grid $frame.attach $frame.run -sticky w < grid $frame.load $frame.cont -sticky w < grid $frame.afterl -sticky we -columnspan 2 < grid $frame.aftere -sticky we -columnspan 2 --- > > grid $frame.label -column 1 -row 0 -sticky w > grid $frame.attach -column 0 -row 1 -ipady 2 > grid $frame.load -column 0 -row 2 -ipady 2 > > grid $run_method.run -column 0 -row 1 -sticky w -ipady 2 > grid $run_method.cont -column 0 -row 2 -sticky w -ipady 2 > > grid $rm_frame -column 1 -row 1 -rowspan 2 -sticky nsew -ipady 2 > > grid $frame.afterl -row 4 -sticky we -columnspan 2 -ipady 2 > grid $frame.aftere -sticky we -columnspan 2 -ipady 2 724a737,745 > > if { "$target" == "exec" } { > $run_method.run configure -state disabled -value 1 > $run_method.cont configure -state disabled > } else { > $run_method.run configure -state normal > $run_method.cont configure -state normal > } > > > > Cheers, > Fernando > > P.S.: Insight patches go to the insight list, not gdb-patches as the people > that wrote the code watch it more closely and there is a larger group of > users and contributors in this list that do not subscribe to gdb-patches. > > Larry Smith wrote: > > > > The following patch is for 100494, changing a pair of checkbuttons > > to radiobuttons. Since the proper behaviour was already enforced > > this is really only cosmetic, and changes no current control flow. > > > > I apologise for being unaware of proper protocol for doing patches > > on sourceware, this has already been checked in. I will try to be > > more circumspect in the future... > > > > regards, > > Larry > > > > 2000-10-26 Larry Smith > > > > * change targetselection.itb: Run Program and Continue From Last Stop > > are now radio buttons rather than checkbuttons > > > > Index: targetselection.itb > > =================================================================== > > RCS file: /cvs/src/src/gdb/gdbtk/library/targetselection.itb,v > > retrieving revision 1.4 > > retrieving revision 1.5 > > diff -u -r1.4 -r1.5 > > --- targetselection.itb 2000/09/12 20:04:11 1.4 > > +++ targetselection.itb 2000/10/26 20:47:57 1.5 > > @@ -488,11 +488,11 @@ > > checkbutton $frame.load -text {Download Program} -variable $var > > > > set var [pref varname gdb/src/run_cont] > > - checkbutton $frame.cont -text {Continue from Last Stop} -variable $var \ > > + radiobutton $frame.cont -text {Continue from Last Stop} -value 1 -variable $var \ > > -command [code $this set_run run] > > > > set var [pref varname gdb/src/run_run] > > - checkbutton $frame.run -text {Run Program} -variable $var \ > > + radiobutton $frame.run -text {Run Program} -value 1 -variable $var \ > > -command [code $this set_run cont] > > > > # The after attaching command entry > > -- > Fernando Nasser > Red Hat Canada Ltd. E-Mail: fnasser@redhat.com > 2323 Yonge Street, Suite #300 > Toronto, Ontario M4P 2C9 -- .-. .-. .---. .---. .-..-. | "Bill Gates is just a monocle | |__ / | \| |-< | |-< > / | and a Persian Cat away from `----'`-^-'`-'`-'`-'`-' `-' | being one of the bad guys in a My opinions only. | James Bond movie." -- D Miller >From spolk@redhat.com Tue Oct 31 09:23:00 2000 From: Syd Polk To: lsmith@redhat.com Cc: Fernando Nasser , gdb-patches@sources.redhat.com, insight@sources.redhat.com Subject: Re: [RFA] 100494 fix Date: Tue, 31 Oct 2000 09:23:00 -0000 Message-id: <39FF00D9.670FE177@redhat.com> References: <200010272126.RAA02584@ozma.smith-house.org> <39FDDFB0.D995A63E@cygnus.com> <39FEFF6D.57CC24A0@smith-house.org> X-SW-Source: 2000-10/msg00302.html Content-length: 5837 Need a ChangeLog entry. Now that the official policy has been clarified, patches should be submitted just to insight@sources.redhat.com, not gdb-patches@sources.redhat.com. And when you get a ChangeLog entry, please post a new message with [RFA] starting the subject. Larry Smith wrote: > > Fernando Nasser wrote: > > > > Good catch Larry. But please add a labeled frame around the radiobuttons, > > will you? The target selection dialog expansion box does look weird with > > two square buttons and two rounds with no explanation. > > > > "Run method" sounds right for the frame label. > > > > If you really want to fix this, make sure the option is set to "run" and > > the buttons greyed if the target "exec" is selected. > > Okay, this is a bit more involved than the previous patch, > but it seems to do what Fernando wants. It adds a new var > to the header file to save the pathnames for the run method > buttons, and when the target selection is changed to "exec", > these buttons are greyed out (and "run" selected) and when > it is anything else, the buttons are active and set to what- > ever the program would have set them to. > > This has NOT been checked in or committed. Permission to > do so? > > > cvs diff -r 1.2 targetselection.ith > Index: targetselection.ith > =================================================================== > RCS file: /cvs/src/src/gdb/gdbtk/library/targetselection.ith,v > retrieving revision 1.2 > diff -r1.2 targetselection.ith > 57a58,59 > > > > variable run_method > > > > > cvs diff -r 1.5 targetselection.itb > Index: targetselection.itb > =================================================================== > RCS file: /cvs/src/src/gdb/gdbtk/library/targetselection.itb,v > retrieving revision 1.5 > diff -r1.5 targetselection.itb > 489a490,493 > > set rm_frame [iwidgets::labeledframe $frame.run_method -labelpos nw -labeltext "Run Method" ] > > set run_method [ $rm_frame childsite ] > > > > set rm_label [label $frame.label -text "Run Method:"] > 491c495 > < radiobutton $frame.cont -text {Continue from Last Stop} -value 1 > -variable $var \ > --- > > radiobutton $run_method.cont -text {Continue from Last Stop} -value 1 -variable $var \ > 495c499 > < radiobutton $frame.run -text {Run Program} -value 1 -variable $var \ > --- > > radiobutton $run_method.run -text {Run Program} -value 1 -variable $var \ > 501,504c505,516 > < grid $frame.attach $frame.run -sticky w > < grid $frame.load $frame.cont -sticky w > < grid $frame.afterl -sticky we -columnspan 2 > < grid $frame.aftere -sticky we -columnspan 2 > --- > > > > grid $frame.label -column 1 -row 0 -sticky w > > grid $frame.attach -column 0 -row 1 -ipady 2 > > grid $frame.load -column 0 -row 2 -ipady 2 > > > > grid $run_method.run -column 0 -row 1 -sticky w -ipady 2 > > grid $run_method.cont -column 0 -row 2 -sticky w -ipady 2 > > > > grid $rm_frame -column 1 -row 1 -rowspan 2 -sticky nsew -ipady 2 > > > > grid $frame.afterl -row 4 -sticky we -columnspan 2 -ipady 2 > > grid $frame.aftere -sticky we -columnspan 2 -ipady 2 > 724a737,745 > > > > if { "$target" == "exec" } { > > $run_method.run configure -state disabled -value 1 > > $run_method.cont configure -state disabled > > } else { > > $run_method.run configure -state normal > > $run_method.cont configure -state normal > > } > > > > > > > > > Cheers, > > Fernando > > > > P.S.: Insight patches go to the insight list, not gdb-patches as the people > > that wrote the code watch it more closely and there is a larger group of > > users and contributors in this list that do not subscribe to gdb-patches. > > > > Larry Smith wrote: > > > > > > The following patch is for 100494, changing a pair of checkbuttons > > > to radiobuttons. Since the proper behaviour was already enforced > > > this is really only cosmetic, and changes no current control flow. > > > > > > I apologise for being unaware of proper protocol for doing patches > > > on sourceware, this has already been checked in. I will try to be > > > more circumspect in the future... > > > > > > regards, > > > Larry > > > > > > 2000-10-26 Larry Smith > > > > > > * change targetselection.itb: Run Program and Continue From Last Stop > > > are now radio buttons rather than checkbuttons > > > > > > Index: targetselection.itb > > > =================================================================== > > > RCS file: /cvs/src/src/gdb/gdbtk/library/targetselection.itb,v > > > retrieving revision 1.4 > > > retrieving revision 1.5 > > > diff -u -r1.4 -r1.5 > > > --- targetselection.itb 2000/09/12 20:04:11 1.4 > > > +++ targetselection.itb 2000/10/26 20:47:57 1.5 > > > @@ -488,11 +488,11 @@ > > > checkbutton $frame.load -text {Download Program} -variable $var > > > > > > set var [pref varname gdb/src/run_cont] > > > - checkbutton $frame.cont -text {Continue from Last Stop} -variable $var \ > > > + radiobutton $frame.cont -text {Continue from Last Stop} -value 1 -variable $var \ > > > -command [code $this set_run run] > > > > > > set var [pref varname gdb/src/run_run] > > > - checkbutton $frame.run -text {Run Program} -variable $var \ > > > + radiobutton $frame.run -text {Run Program} -value 1 -variable $var \ > > > -command [code $this set_run cont] > > > > > > # The after attaching command entry > > > > -- > > Fernando Nasser > > Red Hat Canada Ltd. E-Mail: fnasser@redhat.com > > 2323 Yonge Street, Suite #300 > > Toronto, Ontario M4P 2C9 > > -- > .-. .-. .---. .---. .-..-. | "Bill Gates is just a monocle > | |__ / | \| |-< | |-< > / | and a Persian Cat away from > `----'`-^-'`-'`-'`-'`-' `-' | being one of the bad guys in a > My opinions only. | James Bond movie." -- D Miller >From msnyder@redhat.com Tue Oct 31 11:24:00 2000 From: Michael Snyder To: Eli Zaretskii Cc: john@Calva.COM, Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, gdb-patches@sources.redhat.com Subject: Re: Patch for gdb5.0; enable hardware watchpoints on UnixWare Date: Tue, 31 Oct 2000 11:24:00 -0000 Message-id: <39FF1BA8.16E3@redhat.com> References: <200010310906.EAA21817@indy.delorie.com> X-SW-Source: 2000-10/msg00303.html Content-length: 1115 Eli Zaretskii wrote: > > > From: "John Hughes" > > Date: Mon, 30 Oct 2000 17:11:58 +0100 > > > > > But all the i386v4-nat.c code has to be conditionalized on > > > UNIXWARE (or better yet, moved to a new i386sco-nat.c file), as > > > i386v4-nat.c is used by x86 Solaris as well, and Solaris uses page > > > faulting instead of debug registers for watchpoints, and would not > > > compile with your patches installed. > > > > Aha. Here's a fixed version of the patch; the i386v4-nat.c changes > > are conditional on UNIXWARE. > > Note that I'm working on a unified watchpoint implementation for all > ia32 targets, based on the code written for the DJGPP port (see > go32-nat.c). This implementation will allow to watch large areas (up > to 16 bytes) and debug register sharing via reference counts (required > for watching overlapping areas) on all ia32 platforms. > > I am trying to make this happen for v5.1, so perhaps changes like this > one should be witheld and not committed, at least until we decide that > I'm not living up to my promises. Is there a reason for them to be withheld? >From msnyder@redhat.com Tue Oct 31 11:51:00 2000 From: Michael Snyder To: Mark Kettenis Cc: gdb-patches@sourceware.cygnus.com, kevinb@cygnus.com Subject: Re: [PATCH]: Extend SVR4 shlib debug changes to SH3 and other targets Date: Tue, 31 Oct 2000 11:51:00 -0000 Message-id: <39FF22BE.2E8E@redhat.com> References: <200010310102.RAA24876@cleaver.cygnus.com> <200010310937.e9V9b4604953@debye.wins.uva.nl> X-SW-Source: 2000-10/msg00304.html Content-length: 2518 Tweaked per feedback and checked in. Mark Kettenis wrote: > > From: Michael Snyder > Date: Mon, 30 Oct 2000 17:02:01 -0800 (PST) > > This change moves the definition of SVR4_SHARED_LIBS into > config/tm-linux.h, so that it will affect all linuxen. > I then add a new file config/sh/tm-linux.h which includes > config/tm-linux.h (as well as sh/tm-sh.h). Finally I add > target-specific definitions of fetch_link_map_offsets, so > that shared libraries can be cross-debugged. > > 2000-10-30 Michael Snyder > > * config/sh/tm-linux.h: New file. Include generic tm-linux.h, > plus tm-sh.h, then define SVR4_FETCH_LINK_MAP_OFFSETS to use > the sh target function instead of the default link map offsets. > * config/sh/sh.mt: Add solib.o and solib-svr4.o to TDEPFILES. > Use sh/tm-linux.h instead of sh/tm-sh.h. > * sh-tdep.c (sh_linux_svr4_fetch_link_map_offsets): > New function. Construct target-specific link map offsets. > * i386-linux-tdep.c (i386_linux_svr4_fetch_link_map_offsets: > New function. Construct target-specific link map offsets. > * config/i386/tm-linux.h: Use above function instead of default. > > 2000-10-30 Michael Snyder > > * config/i386/tm-linux.h: Remove definition of SVR4_SHARED_LIBS, > and inclusion of solib.h. Move up into ../tm-linux.h. > config/tm-linux.h: Define SVR4_SHARED_LIBS, include solib.h. > > Looks good to me. One minor nit though: > > Index: config/tm-linux.h > =================================================================== > RCS file: /cvs/src/src/gdb/config/tm-linux.h,v > retrieving revision 1.1.1.1 > diff -c -3 -p -r1.1.1.1 tm-linux.h > *** tm-linux.h 1999/12/07 03:56:08 1.1.1.1 > --- tm-linux.h 2000/10/31 00:57:12 > *************** > *** 34,36 **** > --- 34,42 ---- > /* We need this file for the SOLIB_TRAMPOLINE stuff. */ > > #include "tm-sysv4.h" > + > + /* We define this if link.h is available, because with ELF we use SVR4 style > + shared libraries. FIXME: move up into config/tm-linux.h? */ > + > + #define SVR4_SHARED_LIBS > + #include "solib.h" /* Support for shared libraries. */ > > Please update the comment. The FIXME can go now, and the blurb about > link.h isn't true anymore isn't it? >From msnyder@cygnus.com Tue Oct 31 14:04:00 2000 From: Michael Snyder To: gdb-patches@sources.redhat.com Subject: [RFA] Encapsulate method of searching for a solib. Date: Tue, 31 Oct 2000 14:04:00 -0000 Message-id: <200010312203.OAA25580@cleaver.cygnus.com> X-SW-Source: 2000-10/msg00305.html Content-length: 9273 The enable_break function from solib-svr4.c needs to use the same search method for shared libs as is used in solib.c (utilizing SOLIB_ABSOLUTE_PREFIX and SOLIB_SEARCH_PATH), so I've abstracted this method into a function and cleaned it up a bit. 2000-10-31 Michael Snyder * solib.c (solib_open): New function. Abstracts the code from solib_map_sections that searches for a solib file. (solib_map_sections): Call solib_open instead of working inline. * solib-svr4.c (enable_break): Call solib_open to find the dynamic linker's base address. * solib-svr4.h (solib_open): Export the declaration. Index: solib.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/solib.c,v retrieving revision 1.154 diff -c -3 -p -r1.154 solib.c *** solib.c 2000/10/31 20:19:49 1.154 --- solib.c 2000/10/31 21:59:52 *************** static char *solib_search_path = NULL; *** 66,71 **** --- 66,150 ---- /* + GLOBAL FUNCTION + + solib_open -- Find a shared library file and open it. + + SYNOPSIS + + int solib_open (char *in_patname, char **found_pathname); + + DESCRIPTION + + Global variable SOLIB_ABSOLUTE_PREFIX is used as a prefix directory + to search for shared libraries if they have an absolute path. + + Global variable SOLIB_SEARCH_PATH is used as a prefix directory + (or set of directories, as in LD_LIBRARY_PATH) to search for all + shared libraries if not found in SOLIB_ABSOLUTE_PREFIX. + + Search order: + * If path is absolute, look in SOLIB_ABSOLUTE_PREFIX. + * If path is absolute, look for it literally (unmodified). + * Look in SOLIB_SEARCH_PATH. + * Look in inferior's $PATH. + * Look in inferior's $LD_LIBRARY_PATH. + + RETURNS + + file handle for opened solib, or -1 for failure. */ + + int + solib_open (char *in_pathname, char **found_pathname) + { + int found_file = -1; + char *temp_pathname = NULL; + + if (solib_absolute_prefix != NULL && + ROOTED_P (in_pathname)) + { + int prefix_len = strlen (solib_absolute_prefix); + + /* Remove trailing slashes from absolute prefix. */ + while (prefix_len > 0 && SLASH_P (solib_absolute_prefix[prefix_len - 1])) + prefix_len--; + + /* Cat the prefixed pathname together. */ + temp_pathname = alloca (prefix_len + strlen (in_pathname) + 1); + strncpy (temp_pathname, solib_absolute_prefix, prefix_len); + temp_pathname[prefix_len] = '\0'; + strcat (temp_pathname, in_pathname); + + /* Now see if we can open it. */ + found_file = open (temp_pathname, O_RDONLY, 0); + } + + /* If not found, next search the solib_search_path (if any). */ + if (found_file < 0 && solib_search_path != NULL) + found_file = openp (solib_search_path, + 1, in_pathname, O_RDONLY, 0, &temp_pathname); + + /* If not found, next search the inferior's $PATH environment variable. */ + if (found_file < 0 && solib_search_path != NULL) + found_file = openp (get_in_environ (inferior_environ, "PATH"), + 1, in_pathname, O_RDONLY, 0, &temp_pathname); + + /* If not found, next search the inferior's $LD_LIBRARY_PATH + environment variable. */ + if (found_file < 0 && solib_search_path != NULL) + found_file = openp (get_in_environ (inferior_environ, "LD_LIBRARY_PATH"), + 1, in_pathname, O_RDONLY, 0, &temp_pathname); + + /* Done. If not found, tough luck. Return found_file and + (optionally) found_pathname. */ + if (found_pathname != NULL) + *found_pathname = strsave (temp_pathname); + return found_file; + } + + + /* + LOCAL FUNCTION solib_map_sections -- open bfd and build sections for shared lib *************** solib_map_sections (PTR arg) *** 104,152 **** filename = tilde_expand (so->so_name); - if (solib_absolute_prefix && ROOTED_P (filename)) - /* Prefix shared libraries with absolute filenames with - SOLIB_ABSOLUTE_PREFIX. */ - { - char *pfxed_fn; - int pfx_len; - - pfx_len = strlen (solib_absolute_prefix); - - /* Remove trailing slashes. */ - while (pfx_len > 0 && SLASH_P (solib_absolute_prefix[pfx_len - 1])) - pfx_len--; - - pfxed_fn = xmalloc (pfx_len + strlen (filename) + 1); - strcpy (pfxed_fn, solib_absolute_prefix); - strcat (pfxed_fn, filename); - free (filename); - - filename = pfxed_fn; - } - old_chain = make_cleanup (free, filename); - scratch_chan = -1; - - if (solib_search_path) - scratch_chan = openp (solib_search_path, - 1, filename, O_RDONLY, 0, &scratch_pathname); - if (scratch_chan < 0) - scratch_chan = openp (get_in_environ (inferior_environ, "PATH"), - 1, filename, O_RDONLY, 0, &scratch_pathname); - if (scratch_chan < 0) - { - scratch_chan = openp (get_in_environ - (inferior_environ, "LD_LIBRARY_PATH"), - 1, filename, O_RDONLY, 0, &scratch_pathname); - } if (scratch_chan < 0) { perror_with_name (filename); } - /* Leave scratch_pathname allocated. abfd->name will point to it. */ abfd = bfd_fdopenr (scratch_pathname, gnutarget, scratch_chan); if (!abfd) { --- 183,197 ---- filename = tilde_expand (so->so_name); old_chain = make_cleanup (free, filename); + scratch_chan = solib_open (filename, &scratch_pathname); if (scratch_chan < 0) { perror_with_name (filename); } + /* Leave scratch_pathname allocated. abfd->name will point to it. */ abfd = bfd_fdopenr (scratch_pathname, gnutarget, scratch_chan); if (!abfd) { *************** solib_map_sections (PTR arg) *** 154,165 **** error ("Could not open `%s' as an executable file: %s", scratch_pathname, bfd_errmsg (bfd_get_error ())); } /* Leave bfd open, core_xfer_memory and "info files" need it. */ so->abfd = abfd; abfd->cacheable = true; ! /* copy full path name into so_name, so that later symbol_file_add can find ! it */ if (strlen (scratch_pathname) >= SO_NAME_MAX_PATH_SIZE) error ("Full path name length of shared library exceeds SO_NAME_MAX_PATH_SIZE in so_list structure."); strcpy (so->so_name, scratch_pathname); --- 199,211 ---- error ("Could not open `%s' as an executable file: %s", scratch_pathname, bfd_errmsg (bfd_get_error ())); } + /* Leave bfd open, core_xfer_memory and "info files" need it. */ so->abfd = abfd; abfd->cacheable = true; ! /* copy full path name into so_name, so that later symbol_file_add ! can find it */ if (strlen (scratch_pathname) >= SO_NAME_MAX_PATH_SIZE) error ("Full path name length of shared library exceeds SO_NAME_MAX_PATH_SIZE in so_list structure."); strcpy (so->so_name, scratch_pathname); Index: solib-svr4.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/solib-svr4.c,v retrieving revision 1.3 diff -c -3 -p -r1.3 solib-svr4.c *** solib-svr4.c 2000/10/31 20:19:49 1.3 --- solib-svr4.c 2000/10/31 21:59:52 *************** enable_break (void) *** 1269,1275 **** unsigned int interp_sect_size; char *buf; CORE_ADDR load_addr; ! bfd *tmp_bfd; CORE_ADDR sym_addr = 0; /* Read the contents of the .interp section into a local buffer; --- 1269,1277 ---- unsigned int interp_sect_size; char *buf; CORE_ADDR load_addr; ! bfd *tmp_bfd = NULL; ! int tmp_fd = -1; ! char *tmp_pathname = NULL; CORE_ADDR sym_addr = 0; /* Read the contents of the .interp section into a local buffer; *************** enable_break (void) *** 1287,1293 **** to find any magic formula to find it for Solaris (appears to be trivial on GNU/Linux). Therefore, we have to try an alternate mechanism to find the dynamic linker's base address. */ ! tmp_bfd = bfd_openr (buf, gnutarget); if (tmp_bfd == NULL) goto bkpt_at_symbol; --- 1289,1299 ---- to find any magic formula to find it for Solaris (appears to be trivial on GNU/Linux). Therefore, we have to try an alternate mechanism to find the dynamic linker's base address. */ ! ! tmp_fd = solib_open (buf, &tmp_pathname); ! if (tmp_fd >= 0) ! tmp_bfd = bfd_fdopenr (tmp_pathname, gnutarget, tmp_fd); ! if (tmp_bfd == NULL) goto bkpt_at_symbol; Index: solib-svr4.h =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/solib-svr4.h,v retrieving revision 1.2 diff -c -3 -p -r1.2 solib-svr4.h *** solib-svr4.h 2000/10/30 22:03:33 1.2 --- solib-svr4.h 2000/10/31 21:59:52 *************** struct link_map_offsets *** 64,69 **** --- 64,72 ---- int l_name_size; }; + /* Find solib binary file and open it. */ + extern int solib_open (char *in_pathname, char **found_pathname); + #ifndef SVR4_FETCH_LINK_MAP_OFFSETS extern struct link_map_offsets *default_svr4_fetch_link_map_offsets (void); #define SVR4_FETCH_LINK_MAP_OFFSETS() default_svr4_fetch_link_map_offsets () >From msnyder@cygnus.com Tue Oct 31 14:09:00 2000 From: Michael Snyder To: gdb-patches@sources.redhat.com Subject: [RFA]: Initialize solib search psth from environ variable Date: Tue, 31 Oct 2000 14:09:00 -0000 Message-id: <200010312209.OAA25598@cleaver.cygnus.com> X-SW-Source: 2000-10/msg00306.html Content-length: 1076 This patch would check the environment variables SOLIB_SEARCH_PATH and SOLIB_ABSOLUTE_PREFIX once, at start-up, and use them to set the corresponding gdb state variables. 2000-10-31 Michael Snyder * solib.c (initialize_solib): Initialize solib_absolute_prefix and solib_search_path from the environment variables SOLIB_ABSOLUTE_PREFIX and SOLIB_SEARCH_PATH, if they're defined. Index: solib.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/solib.c,v retrieving revision 1.155 diff -c -3 -p -r1.155 solib.c *** solib.c 2000/10/31 22:04:12 1.155 --- solib.c 2000/10/31 22:08:17 *************** This takes precedence over the environme *** 810,813 **** --- 810,819 ---- &setlist), &showlist); + /* check for solib path environment variables */ + if ((tmp = getenv ("SOLIB_ABSOLUTE_PREFIX")) != NULL) + solib_absolute_prefix = strsave (tmp); + + if ((tmp = getenv ("SOLIB_SEARCH_PATH")) != NULL) + solib_search_path = strsave (tmp); } >From jtc@redback.com Tue Oct 31 15:14:00 2000 From: jtc@redback.com (J.T. Conklin) To: Eli Zaretskii Cc: msalter@redhat.com, gdb-patches@sources.redhat.com Subject: Re: Remote watchpoint support. Date: Tue, 31 Oct 2000 15:14:00 -0000 Message-id: <5mpukgli1x.fsf@jtc.redback.com> References: <200010301416.e9UEG6m18981@deneb.localdomain> <5mg0leoyg6.fsf@jtc.redback.com> <200010310906.EAA21820@indy.delorie.com> X-SW-Source: 2000-10/msg00307.html Content-length: 2051 >>>>> "Eli" == Eli Zaretskii writes: >> The second is the return value of 0 if the target stopped for another >> reason. I (now) know that this is the current behavior of the target_ >> stopped_data_address() macro, but it use the one address that I think >> might be very important to watch on targets where the zero page isn't >> unmapped (in which case a reference would cause a exception/trap). Eli> I would actually be very happy if we could change the interface of Eli> target_stopped_data_address so that zero would not be treated Eli> specially. One problem with the current design is that I cannot catch Eli> NULL pointer dereferences on Windows, where the null page cannot be Eli> unmapped from the address space of DJGPP programs. This prevents me Eli> from finding such bugs by setting a watchpoint at address 0. Did I just hear an echo? :-) I'm glad you agree that this is a bug. >> While it might not be possible to fix in GDB's internals for some >> time Eli> What would it take to change that? Perhaps it would be a good Eli> idea to have the list of the obstacles, in case someone might try Eli> to negotiate them one by one. I was being pessimistic, perhaps overly so, in my assessment of fixing GDB to emphasize my point that we shouldn't constrain the remote debug protocol around internal implementation details. Given a bit of hard work, many limitations within GDB can be easily fixed; but the remote protocol has a permanence that makes it worth our while to get it right the first time. Otherwise we'll forever be saddled with supporting old stubs with the flawed implementation. In this case, I don't think it would be that difficult to fix. For a first cut, I'd change the macro to: target_stopped_data_address(&addr) It would return 0 if GDB didn't stop because of a watchpoint, and 1 (and set addr) if it did. I don't know if there are any other lurking problems for watching address 0. I'm sure they'd show up pretty soon. --jtc -- J.T. Conklin RedBack Networks >From kevinb@cygnus.com Tue Oct 31 16:23:00 2000 From: Kevin Buettner To: Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: [RFA] Encapsulate method of searching for a solib. Date: Tue, 31 Oct 2000 16:23:00 -0000 Message-id: <1001101002345.ZM4449@ocotillo.lan> References: <200010312203.OAA25580@cleaver.cygnus.com> X-SW-Source: 2000-10/msg00308.html Content-length: 912 On Oct 31, 2:03pm, Michael Snyder wrote: > The enable_break function from solib-svr4.c needs to use the same > search method for shared libs as is used in solib.c (utilizing > SOLIB_ABSOLUTE_PREFIX and SOLIB_SEARCH_PATH), so I've abstracted > this method into a function and cleaned it up a bit. > > 2000-10-31 Michael Snyder > > * solib.c (solib_open): New function. Abstracts the code from > solib_map_sections that searches for a solib file. > (solib_map_sections): Call solib_open instead of working inline. > * solib-svr4.c (enable_break): Call solib_open to find the > dynamic linker's base address. > * solib-svr4.h (solib_open): Export the declaration. This looks good to me, but Jim Blandy is the official maintainer of these files, so if you want "official maintainer approval", you'll have to check with him. Kevin >From kevinb@cygnus.com Tue Oct 31 16:28:00 2000 From: Kevin Buettner To: Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: [RFA] Encapsulate method of searching for a solib. Date: Tue, 31 Oct 2000 16:28:00 -0000 Message-id: <1001101002807.ZM4469@ocotillo.lan> References: <200010312203.OAA25580@cleaver.cygnus.com> X-SW-Source: 2000-10/msg00309.html Content-length: 405 On Oct 31, 2:03pm, Michael Snyder wrote: > * solib-svr4.h (solib_open): Export the declaration. Woops. Now that I stare at it a bit longer, I think that the exported declaration ought to go somewhere else. I suggest solist.h. (Actually, I think we ought to rename solist.h to solib-private.h. The intent is that it should only be included by solib.c and the various solib backends.) Kevin >From msnyder@redhat.com Tue Oct 31 16:29:00 2000 From: Michael Snyder To: Kevin Buettner Cc: Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: [RFA] Encapsulate method of searching for a solib. Date: Tue, 31 Oct 2000 16:29:00 -0000 Message-id: <39FF63EB.690D@redhat.com> References: <200010312203.OAA25580@cleaver.cygnus.com> <1001101002807.ZM4469@ocotillo.lan> X-SW-Source: 2000-10/msg00310.html Content-length: 503 Kevin Buettner wrote: > > On Oct 31, 2:03pm, Michael Snyder wrote: > > > * solib-svr4.h (solib_open): Export the declaration. > > Woops. Now that I stare at it a bit longer, I think that the > exported declaration ought to go somewhere else. I suggest > solist.h. (Actually, I think we ought to rename solist.h to > solib-private.h. The intent is that it should only be included > by solib.c and the various solib backends.) You're the second one to say so. OK, I'll make that change. >From msnyder@cygnus.com Tue Oct 31 16:33:00 2000 From: Michael Snyder To: gdb-patches@sources.redhat.com Subject: [RFA] Call SOLIB_CREATE_INFERIOR_HOOK for remote targets. Date: Tue, 31 Oct 2000 16:33:00 -0000 Message-id: <200011010033.QAA25682@cleaver.cygnus.com> X-SW-Source: 2000-10/msg00311.html Content-length: 1231 I want to add this call to remote_open, so that we can debug shared libraries on a remote target. This works together with Kevin Buettner's recent changes to the solib code. 2000-10-31 Michael Snyder * remote.c (remote_open): Call SOLIB_CREATE_INFERIOR_HOOK (if defined), so that shared libraries can be detected. Index: remote.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/remote.c,v retrieving revision 1.290 diff -c -3 -p -r1.290 remote.c *** remote.c 2000/10/25 12:55:39 1.290 --- remote.c 2000/11/01 00:31:00 *************** *** 51,56 **** --- 51,57 ---- #include #include "serial.h" + #include "gdbcore.h" /* for exec_bfd */ /* Prototypes for local functions */ static void cleanup_sigint_signal_handler (void *dummy); *************** static void *** 2000,2005 **** --- 2001,2010 ---- remote_open (char *name, int from_tty) { remote_open_1 (name, from_tty, &remote_ops, 0); + #ifdef SOLIB_CREATE_INFERIOR_HOOK + if (exec_bfd) /* no use without one... */ + SOLIB_CREATE_INFERIOR_HOOK (inferior_pid); + #endif } /* Just like remote_open, but with asynchronous support. */ >From kevinb@cygnus.com Tue Oct 31 16:36:00 2000 From: Kevin Buettner To: Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: [RFA]: Initialize solib search psth from environ variable Date: Tue, 31 Oct 2000 16:36:00 -0000 Message-id: <1001101003556.ZM4496@ocotillo.lan> References: <200010312209.OAA25598@cleaver.cygnus.com> X-SW-Source: 2000-10/msg00312.html Content-length: 704 On Oct 31, 2:09pm, Michael Snyder wrote: > This patch would check the environment variables SOLIB_SEARCH_PATH > and SOLIB_ABSOLUTE_PREFIX once, at start-up, and use them to set the > corresponding gdb state variables. > > 2000-10-31 Michael Snyder > > * solib.c (initialize_solib): Initialize solib_absolute_prefix > and solib_search_path from the environment variables > SOLIB_ABSOLUTE_PREFIX and SOLIB_SEARCH_PATH, if they're defined. I think this one's okay too so long as we've all agreed that concept of initializing bits of gdb state from environment variables is acceptable. (But again, Jim Blandy is the official maintainer...) Kevin >From ac131313@cygnus.com Tue Oct 31 18:32:00 2000 From: Andrew Cagney To: Michael Snyder Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Call SOLIB_CREATE_INFERIOR_HOOK for remote targets. Date: Tue, 31 Oct 2000 18:32:00 -0000 Message-id: <39FF7CDB.839743CD@cygnus.com> References: <200011010033.QAA25682@cleaver.cygnus.com> X-SW-Source: 2000-10/msg00314.html Content-length: 1438 Michael Snyder wrote: > > I want to add this call to remote_open, so that we can debug shared > libraries on a remote target. This works together with Kevin Buettner's > recent changes to the solib code. > > 2000-10-31 Michael Snyder > > * remote.c (remote_open): Call SOLIB_CREATE_INFERIOR_HOOK > (if defined), so that shared libraries can be detected. FYI, There are currently several remote opens so they would each needed to be updated. Andrew > Index: remote.c > =================================================================== > RCS file: /cvs/cvsfiles/devo/gdb/remote.c,v > retrieving revision 1.290 > diff -c -3 -p -r1.290 remote.c > *** remote.c 2000/10/25 12:55:39 1.290 > --- remote.c 2000/11/01 00:31:00 > *************** > *** 51,56 **** > --- 51,57 ---- > > #include > #include "serial.h" > + #include "gdbcore.h" /* for exec_bfd */ > > /* Prototypes for local functions */ > static void cleanup_sigint_signal_handler (void *dummy); > *************** static void > *** 2000,2005 **** > --- 2001,2010 ---- > remote_open (char *name, int from_tty) > { > remote_open_1 (name, from_tty, &remote_ops, 0); > + #ifdef SOLIB_CREATE_INFERIOR_HOOK > + if (exec_bfd) /* no use without one... */ > + SOLIB_CREATE_INFERIOR_HOOK (inferior_pid); > + #endif > } > > /* Just like remote_open, but with asynchronous support. */ >From ac131313@cygnus.com Tue Oct 31 18:32:00 2000 From: Andrew Cagney To: Michael Snyder Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA]: Initialize solib search psth from environ variable Date: Tue, 31 Oct 2000 18:32:00 -0000 Message-id: <39FF65A0.6E019C53@cygnus.com> References: <200010312209.OAA25598@cleaver.cygnus.com> X-SW-Source: 2000-10/msg00313.html Content-length: 2085 Michael Snyder wrote: > > This patch would check the environment variables SOLIB_SEARCH_PATH > and SOLIB_ABSOLUTE_PREFIX once, at start-up, and use them to set the > corresponding gdb state variables. > > 2000-10-31 Michael Snyder > > * solib.c (initialize_solib): Initialize solib_absolute_prefix > and solib_search_path from the environment variables > SOLIB_ABSOLUTE_PREFIX and SOLIB_SEARCH_PATH, if they're defined. As it currently stands, I don't like this patch. It introduces (more) obscure undocumented behavour into GDB and its CLI. I think there first needs to be a clear policy on the question of should a GDB (native or cross) take information from the host environment (1). Then, if the decision is yes, a clearly documented convention on how to implement this behavour (nameing convention, semantics, ...). My personal preference is to not add this feature. I think that .gdbinit files and explicit command line options/commands would be more useful. Having GDB silently pick things up from a host environment (especially in a test situtation) will just make things more confusing. enjoy, Andrew (1) I should note that a native GDB does take environment-variables from the ``target'' environment. It is just that, in a native situtation, the distinction between host and target gets pretty blured. > Index: solib.c > =================================================================== > RCS file: /cvs/cvsfiles/devo/gdb/solib.c,v > retrieving revision 1.155 > diff -c -3 -p -r1.155 solib.c > *** solib.c 2000/10/31 22:04:12 1.155 > --- solib.c 2000/10/31 22:08:17 > *************** This takes precedence over the environme > *** 810,813 **** > --- 810,819 ---- > &setlist), > &showlist); > > + /* check for solib path environment variables */ > + if ((tmp = getenv ("SOLIB_ABSOLUTE_PREFIX")) != NULL) > + solib_absolute_prefix = strsave (tmp); > + > + if ((tmp = getenv ("SOLIB_SEARCH_PATH")) != NULL) > + solib_search_path = strsave (tmp); > } >From cgf@redhat.com Tue Oct 31 20:31:00 2000 From: Christopher Faylor To: gdb-patches@sources.redhat.com Subject: Re: [RFA]: Initialize solib search psth from environ variable Date: Tue, 31 Oct 2000 20:31:00 -0000 Message-id: <20001031233120.G6215@redhat.com> References: <200010312209.OAA25598@cleaver.cygnus.com> <39FF65A0.6E019C53@cygnus.com> X-SW-Source: 2000-10/msg00315.html Content-length: 1722 On Wed, Nov 01, 2000 at 11:36:48AM +1100, Andrew Cagney wrote: >Michael Snyder wrote: >> >> This patch would check the environment variables SOLIB_SEARCH_PATH >> and SOLIB_ABSOLUTE_PREFIX once, at start-up, and use them to set the >> corresponding gdb state variables. >> >> 2000-10-31 Michael Snyder >> >> * solib.c (initialize_solib): Initialize solib_absolute_prefix >> and solib_search_path from the environment variables >> SOLIB_ABSOLUTE_PREFIX and SOLIB_SEARCH_PATH, if they're defined. > >As it currently stands, I don't like this patch. It introduces (more) >obscure undocumented behavour into GDB and its CLI. > >I think there first needs to be a clear policy on the question of should >a GDB (native or cross) take information from the host environment (1). >Then, if the decision is yes, a clearly documented convention on how to >implement this behavour (nameing convention, semantics, ...). > >My personal preference is to not add this feature. I think that >.gdbinit files and explicit command line options/commands would be more >useful. Having GDB silently pick things up from a host environment >(especially in a test situtation) will just make things more confusing. I agree with this. When I first started working on Cygwin, I pushed to have all of the various environment variables eliminated in favor of one environment variable called 'CYGWIN'. I didn't want to engender the overhead of reading a file in Cygwin's case, or I might have lobbied for that, too. If we do decide to use environment variables, how about just using one? In that case we could have something like: export GDB='solib_absolute_prefix solib_search_path' cgf >From ac131313@cygnus.com Tue Oct 31 23:00:00 2000 From: Andrew Cagney To: "Christopher G. Faylor" Cc: GDB Patches Subject: People can subscribe to gdb-prs via the web Date: Tue, 31 Oct 2000 23:00:00 -0000 Message-id: <39FFBE2F.AE53AEB4@cygnus.com> X-SW-Source: 2000-10/msg00316.html Content-length: 320 FYI, I've added gdb-prs to the list of subscribe options on the home page (and after three attempts it appears to work :-) http://sources.redhat.com/gdb/#mailing-lists This doesn't answer the gdb-prs->gdb question though. Once the fine tuning has finished you should definitly announce this on gdb-announce. Andrew >From toddpw@best.com Wed Nov 01 00:11:00 2000 From: Todd Whitesel To: Peter.Schauer@regent.e-technik.tu-muenchen.de (Peter.Schauer) Cc: aoliva@redhat.com, Peter.Schauer@regent.e-technik.tu-muenchen.de, msnyder@redhat.com, kettenis@wins.uva.nl, gdb-patches@sourceware.cygnus.com, rfolden@cygnus.com, ebachalo@cygnus.com, jld@cygnus.com Subject: Re: [DISCUSS]: cross-debugging shared libraries Date: Wed, 01 Nov 2000 00:11:00 -0000 Message-id: <200011010809.AAA26460@shell17.ba.best.com> References: <200010261009.MAA09821@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-11/msg00000.html Content-length: 317 > Looks better, but I still think that GDB should use getenv only if absolutely > necessary. Strongly Agree. Especially when using one GDB to debug another, environment cross-talk can be a real headache. GCC_EXEC_PREFIX seems like a neat idea, but then cross-compilation happened. Todd Whitesel toddpw @ best.com >From kettenis@wins.uva.nl Wed Nov 01 01:12:00 2000 From: Mark Kettenis To: eliz@is.elta.co.il Cc: john@Calva.COM, gdb-patches@sources.redhat.com Subject: Re: Patch for gdb5.0; enable hardware watchpoints on UnixWare Date: Wed, 01 Nov 2000 01:12:00 -0000 Message-id: <200011010912.eA19C1j05992@debye.wins.uva.nl> References: <200010311710.MAA22110@indy.delorie.com> X-SW-Source: 2000-11/msg00001.html Content-length: 1287 Date: Tue, 31 Oct 2000 12:10:42 -0500 (EST) From: Eli Zaretskii > > While I generalize the code, I will bring it up to date with the letter > > of Intel's manuals. > > So you're going to have your own defines for DR_... and not use the > system ones? I guess that was why your code didn't match up to what > I find in sys/debugreg.h on my system. I was unaware of sys/debugreg.h until now. Is it present on all Unix x86-based systems? If not, we will need some configury magic to handle this. DJGPP certainly doesn't have sys/debugreg.h, and I don't know how about Cygwin. What do people think about relative merits of using sys/debugreg.h vs having the definitions inside GDB (or both)? Forget about sys/debugreg.h. Some Linux systems have it, some don't. And any dependency on target-specific header files is a PITA when building a cross-debugger. IMHO having definitions inside GDB that match the Intel documentation is probably the best thing to do. I don't think that the layout of the debug registers differs between any x86 targets. Any differences in register numbering should be addressed by the system-dependcent layer, and any native version of that code could use sys/debugreg.h if it wants. Mark >From eliz@delorie.com Wed Nov 01 01:27:00 2000 From: Eli Zaretskii To: msnyder@redhat.com Cc: john@Calva.COM, Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, gdb-patches@sources.redhat.com Subject: Re: Patch for gdb5.0; enable hardware watchpoints on UnixWare Date: Wed, 01 Nov 2000 01:27:00 -0000 Message-id: <200011010924.EAA22677@indy.delorie.com> References: <200010310906.EAA21817@indy.delorie.com> <39FF1BA8.16E3@redhat.com> X-SW-Source: 2000-11/msg00002.html Content-length: 1159 > Date: Tue, 31 Oct 2000 11:21:12 -0800 > From: Michael Snyder > > Eli Zaretskii wrote: > > > > Note that I'm working on a unified watchpoint implementation for all > > ia32 targets, based on the code written for the DJGPP port (see > > go32-nat.c). This implementation will allow to watch large areas (up > > to 16 bytes) and debug register sharing via reference counts (required > > for watching overlapping areas) on all ia32 platforms. > > > > I am trying to make this happen for v5.1, so perhaps changes like this > > one should be witheld and not committed, at least until we decide that > > I'm not living up to my promises. > > Is there a reason for them to be withheld? I thought what I wrote was the reason. But if you think it's not a reason, or that it's not important enough, by all means go ahead and commit the changes; that's why I said ``perhaps'' in my last sentence. In case my wording wasn't clear: adding yet another subtly incompatible watchpoint implementation for ia32 target might be largely a wasted effort, since they all will have to be revisited when/if the generalized code is finished and accepted. >From eliz@delorie.com Wed Nov 01 01:28:00 2000 From: Eli Zaretskii To: msnyder@redhat.com Cc: john@Calva.COM, Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, gdb-patches@sources.redhat.com Subject: Re: Patch for gdb5.0; enable hardware watchpoints on UnixWare Date: Wed, 01 Nov 2000 01:28:00 -0000 Message-id: <200011010924.EAA22680@indy.delorie.com> References: <200010310906.EAA21817@indy.delorie.com> <39FF1BA8.16E3@redhat.com> X-SW-Source: 2000-11/msg00003.html Content-length: 3038 > Date: Tue, 31 Oct 2000 11:21:12 -0800 > From: Michael Snyder > > Eli Zaretskii wrote: > > > > Note that I'm working on a unified watchpoint implementation for all > > ia32 targets, based on the code written for the DJGPP port (see > > go32-nat.c). This implementation will allow to watch large areas (up > > to 16 bytes) and debug register sharing via reference counts (required To: jtc@redback.com CC: msalter@redhat.com, gdb-patches@sources.redhat.com In-reply-to: <5mpukgli1x.fsf@jtc.redback.com> Subject: Re: Remote watchpoint support. Reply-to: Eli Zaretskii References: <200010301416.e9UEG6m18981@deneb.localdomain> <5mg0leoyg6.fsf@jtc.redback.com> <200010310906.EAA21820@indy.delorie.com> <5mpukgli1x.fsf@jtc.redback.com> --text follows this line-- > From: jtc@redback.com (J.T. Conklin) > Date: 31 Oct 2000 15:14:34 -0800 > > Did I just hear an echo? :-) Yes. Isn't it true that echoes are so reassuring? ;-) > In this case, I don't think it would be that difficult to fix. For a > first cut, I'd change the macro to: > > target_stopped_data_address(&addr) > > It would return 0 if GDB didn't stop because of a watchpoint, and 1 > (and set addr) if it did. That's what I had in mind. I thought you saw some specific problems to make such a change. In addition, I think it might be a good idea for breakpoint.c to use STOPPED_BY_WATCHPOINT in the loop where it tests whether any of the watchpoints triggered. Using target_stopped_data_address for that, as GDB does now, is inefficient: since the target end doesn't know whether GDB needs the address or not, it is forced to do lots of redundant work interrogating the debug interface. The target end needs to find out, for each one of the watchpoints, whether or not it triggered, because the target_stopped_data_address API doesn't include the information about a specific watchpoint. If you have several active watchpoints, this tends to an O(n^2) behavior, since GDB itself loops over all the watchpoints. (I'm guessing that this API peculiarity dates back to the first platforms where watchpoints became available, where watchpoints watched a very large area.) Is there any reason why GDB couldn't use STOPPED_BY_WATCHPOINT inside bpstat_stop_status? > > for watching overlapping areas) on all ia32 platforms. > > > > I am trying to make this happen for v5.1, so perhaps changes like this > > one should be witheld and not committed, at least until we decide that > > I'm not living up to my promises. > > Is there a reason for them to be withheld? I thought what I wrote was the reason. But if you think it's not a reason, or that it's not important enough, by all means go ahead and commit the changes; that's why I said ``perhaps'' in my last sentence. In case my wording wasn't clear: adding yet another subtly incompatible watchpoint implementation for ia32 target might be largely a wasted effort, since they all will have to be revisited when/if the generalized code is finished and accepted. >From eliz@delorie.com Wed Nov 01 01:51:00 2000 From: Eli Zaretskii To: jtc@redback.com Cc: msalter@redhat.com, gdb-patches@sources.redhat.com Subject: Re: Remote watchpoint support. Date: Wed, 01 Nov 2000 01:51:00 -0000 Message-id: <200011010951.EAA22695@indy.delorie.com> References: <200010301416.e9UEG6m18981@deneb.localdomain> <5mg0leoyg6.fsf@jtc.redback.com> <200010310906.EAA21820@indy.delorie.com> <5mpukgli1x.fsf@jtc.redback.com> X-SW-Source: 2000-11/msg00004.html Content-length: 1481 > From: jtc@redback.com (J.T. Conklin) > Date: 31 Oct 2000 15:14:34 -0800 > > Did I just hear an echo? :-) Yes. Isn't it true that echoes are so reassuring? ;-) > In this case, I don't think it would be that difficult to fix. For a > first cut, I'd change the macro to: > > target_stopped_data_address(&addr) > > It would return 0 if GDB didn't stop because of a watchpoint, and 1 > (and set addr) if it did. That's what I had in mind. I thought you saw some specific problems to make such a change. In addition, I think it might be a good idea for breakpoint.c to use STOPPED_BY_WATCHPOINT in the loop where it tests whether any of the watchpoints triggered. Using target_stopped_data_address for that, as GDB does now, is inefficient: since the target end doesn't know whether GDB needs the address or not, it is forced to do lots of redundant work interrogating the debug interface. The target end needs to find out, for each one of the watchpoints, whether or not it triggered, because the target_stopped_data_address API doesn't include the information about a specific watchpoint. If you have several active watchpoints, this tends to an O(n^2) behavior, since GDB itself loops over all the watchpoints. (I'm guessing that this API peculiarity dates back to the first platforms where watchpoints became available, where watchpoints watched a very large area.) Is there any reason why GDB couldn't use STOPPED_BY_WATCHPOINT inside bpstat_stop_status? >From ac131313@cygnus.com Wed Nov 01 02:49:00 2000 From: Andrew Cagney To: jtc@redback.com Cc: Eli Zaretskii , msalter@redhat.com, gdb-patches@sources.redhat.com Subject: Re: Remote watchpoint support. Date: Wed, 01 Nov 2000 02:49:00 -0000 Message-id: <39FFF3F9.255AD722@cygnus.com> References: <200010301416.e9UEG6m18981@deneb.localdomain> <5mg0leoyg6.fsf@jtc.redback.com> <200010310906.EAA21820@indy.delorie.com> <5mpukgli1x.fsf@jtc.redback.com> X-SW-Source: 2000-11/msg00005.html Content-length: 439 "J.T. Conklin" wrote: > In this case, I don't think it would be that difficult to fix. For a > first cut, I'd change the macro to: > > target_stopped_data_address(&addr) > > It would return 0 if GDB didn't stop because of a watchpoint, and 1 > (and set addr) if it did. The trend has been towards (well ok, I've in gdbarch used): int target_stopped_data_address_p (); void target_stopped_data_address (..); enjoy, Andrew >From ac131313@cygnus.com Wed Nov 01 03:05:00 2000 From: Andrew Cagney To: jtc@redback.com Cc: Michael Snyder , Mark Salter , gdb-patches@sources.redhat.com Subject: Re: Remote watchpoint support. Date: Wed, 01 Nov 2000 03:05:00 -0000 Message-id: <39FFF7A3.92440071@cygnus.com> References: <200010301416.e9UEG6m18981@deneb.localdomain> <39FDCF55.46BD@redhat.com> <5m66maoxdo.fsf@jtc.redback.com> X-SW-Source: 2000-11/msg00006.html Content-length: 1934 "J.T. Conklin" wrote: > > >>>>> "Michael" == Michael Snyder writes: > > >> Mark Salter wrote: > >> I'm adding hw break/watchpoint support to a remote target. I'm using > >> the Z-packet support that is in remote.c to install/remove the > >> watchpoints and breakpoints. When a watchpoint is triggered by a > >> read access, GDB needs a way to tell if the target stopped because > >> of the watchpoint. This is done through a target specific function: > > Michael> That really sounds like more of a gdb thing. xxx-tdep.c > Michael> should have the knowledge about the registers, though, not > Michael> remote.c. > > Well, that's one thing that Mark's change has going for it. Like the > "Z" packet, the proposed "qWaddr" packet knows nothing about how the > target implements hardware break/watchpoints. Those details are left > up to the debug agent. While it's probably processor debug registers, > it could be an external device that speaks the remote debug protocol > and talks to the target over BDM or some other on-chip-debugging tech- > nology. Yes. There are two largely independant cases: o gdb talking to a fully functioned target. Here the target is responsible for controling things like break/watch points and consequently is also responsible for returning indications that a break/watchpoint was reached. A remote target that supports Z packets is an example of this. (only as Mark has pointed out, it has limited functionality) o gdb talking to a minimal raw target. Here gdb implements the break/watch point functionality by directly accesing things like registers. x86 watchpoint registers is (?) an example of this one. Before anyone tries to argue that one or the other is better, I think they both are. They solve different problems :-). Now if only the target vector was sufficiently clean to allow these to be stacked .... :-) Andrew >From ac131313@cygnus.com Wed Nov 01 03:19:00 2000 From: Andrew Cagney To: Kevin Buettner Cc: Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: [RFA] Encapsulate method of searching for a solib. Date: Wed, 01 Nov 2000 03:19:00 -0000 Message-id: <39FFFAD2.2357785@cygnus.com> References: <200010312203.OAA25580@cleaver.cygnus.com> <1001101002807.ZM4469@ocotillo.lan> X-SW-Source: 2000-11/msg00007.html Content-length: 749 Kevin Buettner wrote: > > On Oct 31, 2:03pm, Michael Snyder wrote: > > > * solib-svr4.h (solib_open): Export the declaration. > > Woops. Now that I stare at it a bit longer, I think that the > exported declaration ought to go somewhere else. I suggest > solist.h. (Actually, I think we ought to rename solist.h to > solib-private.h. The intent is that it should only be included > by solib.c and the various solib backends.) I'd suggest any thoughts of renaming the file to solib-private.h be discussed separatly. There are a number of other places in GDB which may also benefit from a better separation of public/private interfaces. So if we're going to adopt a change we might as well think a little first :-) enjoy, Andrew >From ac131313@cygnus.com Wed Nov 01 03:36:00 2000 From: Andrew Cagney To: jtc@redback.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [RFA]: Changes to move dcache above target vector functions. Date: Wed, 01 Nov 2000 03:36:00 -0000 Message-id: <39FFFED9.226B5E4F@cygnus.com> References: <5md7hjnd5v.fsf@jtc.redback.com> X-SW-Source: 2000-11/msg00008.html Content-length: 911 "J.T. Conklin" wrote: > > Early last month, I trolled for comments about the enclosed patch. > The only bite I got was about my suggestion that reset is a higher > level concept and probably deserves a separate command / target > function. > > I'd seeking approval to commit the enclosed patch. It's the same as > the earlier one, except I "fixed" the problem with invalidating the > dcache in ocd.c's bdm_reset_command(). This was fixed by accessing > target_dcache in ocd.c. This is an abstraction layer violation, but > it seemed the most expedient way to handle the problem. Support for a > reset command would make this hack unnecessary. I'm open to changing > this if necessary. This is certainly ok with me. As they say two giant leaps forward and a small step back. Just mention the reset command issue (with a URL link) in the TODO file. Andrew (Yes I did notice the pre-existing goto :-) >From ac131313@cygnus.com Wed Nov 01 03:53:00 2000 From: Andrew Cagney To: Orjan Friberg Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Submission of a new gdb port Date: Wed, 01 Nov 2000 03:53:00 -0000 Message-id: <3A0002D9.2BAD4903@cygnus.com> References: <39D837F0.9E376923@axis.com> X-SW-Source: 2000-11/msg00009.html Content-length: 2866 Orjan Friberg wrote: > > I am planning the submission of a new gdb port, and I would appreciate > some guidance as to the best procedure to do this. > > The port is for an embedded system. The current status of the code is > that there are no deprecated macros, but I have not yet switched to the > multi-arch framework. During development, I used the 2000-05-19-release > source tree, but I just updated to the latest CVS sources. > > * Will I be working with anyone in particular? Will the code be > scrutinized in the same way patches are? You'll need to work with a number of people (check the S390 posts). Some parts of a GDB release are part of GDB but some are not. BFD, for instance, is really part of binutils so changes to that go to the binutils@sources.cygnus.com mailing list. Top level changes are discussed in src/MAINTAINERS. In terms of process, I'd not follow IBM's lead with the s390 - they are in a somewhat unusual situtation. The 68hc11 is probably more typical of what should happen - the basic thing was committed and then as second and later passes various issues were resolved. I'd be looking to breakdown your submittion in to smaller chunks and then farming them out. On GDB, once the basics such as file names have been resolved, there can be a fairly large degree of flexability in now things are integrated. > * How stable is the multi-arch framework? Are there any catches > switching to it? (Will multi-arching allow me to debug APIs that only > differ in their respective sizes of a double?) Definitly useable. Many targets have basicly converted, and yes, it lets you do things like change the size of a double (and a lot more :-). The MIPS target knows how to debug well over 30 different ISA/ABI combinations.... > * Which currently supported target would be the best example for > architectural issues? Already being multi-arched, I reckon that the d10v > and the mn10300 are good candidates. Yes. > * Should I submit test results from the DejaGnu testsuite? Should I > submit patches for XFAILs specific to my target? People will be interested in testsuite results but, for the most part, it is the responsibility of the target developer to keep track of such things. You should probably also note that an XFAIL doesn't mean ``I know this doesn't work for my target''. Rather it means something like ``technical issues outside of GDBs control make fixing this impossible''. > * The 4.18 port, on which the 5.0 port is heavily based, was developed > by another person at my company (for which an assign.future has been > submitted previously). How do I give proper credit to him? If they authored the original files then probably mention them as part of the copyright (along with your company and you :-). > Thanks for bearing with me on this. Not a problem, sory to be so slow in responding. Andrew >From ac131313@cygnus.com Wed Nov 01 04:30:00 2000 From: Andrew Cagney To: GDB Patches Subject: [patch] Move h/w watchpoints to 5.2. + misc Date: Wed, 01 Nov 2000 04:30:00 -0000 Message-id: <3A000B86.1A4E67BD@cygnus.com> X-SW-Source: 2000-11/msg00010.html Content-length: 3063 FYI, Per my previous e-mail, the hardware watchpoint stuff that H.J. raised is part of the 5.2 release criteria. If it makes it in 5.1 then it is a bonus. Andrew Wed Nov 1 23:07:29 2000 Andrew Cagney * TODO: Document cleanup to function monitor.dumpregs. Move hardware watchpoint notes to 5.2. Index: TODO =================================================================== RCS file: /cvs/src/src/gdb/TODO,v retrieving revision 1.51 diff -p -r1.51 TODO *** TODO 2000/10/23 22:49:28 1.51 --- TODO 2000/11/01 12:26:40 *************** cycle. People hope to have these proble *** 12,37 **** -- - Hardware watchpint problems on x86 OSes, including Linux: - - 1. Delete/disable hardware watchpoints should free hardware debug - registers. - 2. Watch for different values on a viariable with one hardware debug - register. - - According to Eli Zaretskii : - - These are not GDB/ia32 issues per se: the above features are all - implemented in the DJGPP port of GDB and work in v5.0. Every - x86-based target should be able to lift the relevant parts of - go32-nat.c and use them almost verbatim. You get debug register - sharing through reference counts, and the ability to watch large - regions (up to 16 bytes) using multiple registers. (The required - infrastructure in high-level GDB application code, mostly in - breakpoint.c, is also working since v5.0.) - - -- - RFD: infrun.c: No bpstat_stop_status call after proceed over break? http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00665.html --- 12,17 ---- *************** Fix at least one thread bug. *** 256,261 **** --- 236,264 ---- -- + Hardware watchpint [sic] problems on x86 OSes, including Linux: + http://sources.redhat.com/ml/gdb/2000-09/msg00005.html + + H.J. Lu writes: + + 1. Delete/disable hardware watchpoints should free hardware debug + registers. + 2. Watch for different values on a viariable with one hardware debug + register. + + According to Eli Zaretskii : + + These are not GDB/ia32 issues per se: the above features are all + implemented in the DJGPP port of GDB and work in v5.0. Every + x86-based target should be able to lift the relevant parts of + go32-nat.c and use them almost verbatim. You get debug register + sharing through reference counts, and the ability to watch large + regions (up to 16 bytes) using multiple registers. (The required + infrastructure in high-level GDB application code, mostly in + breakpoint.c, is also working since v5.0.) + + -- + GDB 5.2 - New features ====================== *************** Rename read_register{,_pid}() to read_un *** 801,806 **** --- 804,813 ---- -- + Change monitor.h:struct monitor.dumpregs to a void function. + + -- + Symbol Support ============== *************** an error (or is interrupted). *** 1785,1790 **** --- 1792,1799 ---- Remove the range and type checking code and documentation, if not going to implement. + + -- # Local Variables: # mode: text >From brolley@redhat.com Wed Nov 01 08:13:00 2000 From: Dave Brolley To: gdb-patches@sources.redhat.com Subject: Re: Patch:RFA:sim testsuite: Options Embedded in Test Cases Date: Wed, 01 Nov 2000 08:13:00 -0000 Message-id: <3A004145.69155672@redhat.com> References: <39FDE57F.A237E2A5@redhat.com> X-SW-Source: 2000-11/msg00011.html Content-length: 862 Approved by Frank Eigler and committed. Dave Dave Brolley wrote: > > Hi, > > The attached patch addresses two issues: > > 1) Yet another attempt at passing the correct cpu to the assembler > when more than one machine is being tested. This time I've defined a > global variable 'cpu_option' which the caller can set to indicate the > name of the option which specifies the cpu. > > 2) Resetting options between test cases. Currently options from > previous test cases are not cleared and sometimes they leak into > subsequent tests. Specifically unsetting them seems to be the only way > to make the "if [info exists