From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24275 invoked by alias); 26 May 2003 23:20:07 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 24221 invoked from network); 26 May 2003 23:20:06 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sources.redhat.com with SMTP; 26 May 2003 23:20:06 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id B419BD34B8; Mon, 26 May 2003 16:19:58 -0700 (PDT) Date: Mon, 26 May 2003 23:20:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] HPUX: Remove (non-useful?) definition of PREPARE_TO_PROCEED Message-ID: <20030526231958.GL11123@gnat.com> References: <20030526211558.GH11123@gnat.com> <20030526220223.GA32360@nevyn.them.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="JgQwtEuHJzHdouWu" Content-Disposition: inline In-Reply-To: <20030526220223.GA32360@nevyn.them.org> User-Agent: Mutt/1.4i X-SW-Source: 2003-05/txt/msg00493.txt.bz2 --JgQwtEuHJzHdouWu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 699 > Would you do me the great favor of retesting with changing > PREPARE_TO_PROCEED to use generic_prepare_to_proceed instead of > hppa_prepare_to_proceed? And if no one objects in a few days, commit > that. Then the rest falls out, since you will have removed one of the > two remaining specializations of this method. Sure. Here is a new patch, no new regressions. As suggested, will commit in a few days, if noone objects. 2003-05-26 J. Brobecker * config/pa/nm-hppah.h (PREPARE_TO_PROCEED): Use the generic prepare_to_proceed procedure instead of the hppa-specific one. * hppa-tdep.c (hppa_prepare_to_proceed): Remove, no longer used. -- Joel --JgQwtEuHJzHdouWu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ptp.diff" Content-length: 4428 Index: config/pa/nm-hppah.h =================================================================== RCS file: /cvs/src/src/gdb/config/pa/nm-hppah.h,v retrieving revision 1.13 diff -c -3 -p -r1.13 nm-hppah.h *** config/pa/nm-hppah.h 5 May 2003 17:56:56 -0000 1.13 --- config/pa/nm-hppah.h 26 May 2003 23:15:35 -0000 *************** *** 55,62 **** /* While this is for use by threaded programs, it doesn't appear * to hurt non-threaded ones. This is used in infrun.c: */ ! #define PREPARE_TO_PROCEED(select_it) hppa_prepare_to_proceed() ! extern int hppa_prepare_to_proceed (void); /* In infptrace.c or infttrace.c: */ #define CHILD_PID_TO_EXEC_FILE --- 55,62 ---- /* While this is for use by threaded programs, it doesn't appear * to hurt non-threaded ones. This is used in infrun.c: */ ! #define PREPARE_TO_PROCEED(select_it) generic_prepare_to_proceed(select_it) ! extern int generic_prepare_to_proceed (int select_it); /* In infptrace.c or infttrace.c: */ #define CHILD_PID_TO_EXEC_FILE Index: hppa-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/hppa-tdep.c,v retrieving revision 1.79 diff -c -3 -p -r1.79 hppa-tdep.c *** hppa-tdep.c 22 May 2003 02:04:05 -0000 1.79 --- hppa-tdep.c 26 May 2003 23:15:32 -0000 *************** unwind_command (char *exp, int from_tty) *** 4673,4764 **** pin (Total_frame_size); } - #ifdef PREPARE_TO_PROCEED - - /* If the user has switched threads, and there is a breakpoint - at the old thread's pc location, then switch to that thread - and return TRUE, else return FALSE and don't do a thread - switch (or rather, don't seem to have done a thread switch). - - Ptrace-based gdb will always return FALSE to the thread-switch - query, and thus also to PREPARE_TO_PROCEED. - - The important thing is whether there is a BPT instruction, - not how many user breakpoints there are. So we have to worry - about things like these: - - o Non-bp stop -- NO - - o User hits bp, no switch -- NO - - o User hits bp, switches threads -- YES - - o User hits bp, deletes bp, switches threads -- NO - - o User hits bp, deletes one of two or more bps - at that PC, user switches threads -- YES - - o Plus, since we're buffering events, the user may have hit a - breakpoint, deleted the breakpoint and then gotten another - hit on that same breakpoint on another thread which - actually hit before the delete. (FIXME in breakpoint.c - so that "dead" breakpoints are ignored?) -- NO - - For these reasons, we have to violate information hiding and - call "breakpoint_here_p". If core gdb thinks there is a bpt - here, that's what counts, as core gdb is the one which is - putting the BPT instruction in and taking it out. - - Note that this implementation is potentially redundant now that - default_prepare_to_proceed() has been added. - - FIXME This may not support switching threads after Ctrl-C - correctly. The default implementation does support this. */ - int - hppa_prepare_to_proceed (void) - { - pid_t old_thread; - pid_t current_thread; - - old_thread = hppa_switched_threads (PIDGET (inferior_ptid)); - if (old_thread != 0) - { - /* Switched over from "old_thread". Try to do - as little work as possible, 'cause mostly - we're going to switch back. */ - CORE_ADDR new_pc; - CORE_ADDR old_pc = read_pc (); - - /* Yuk, shouldn't use global to specify current - thread. But that's how gdb does it. */ - current_thread = PIDGET (inferior_ptid); - inferior_ptid = pid_to_ptid (old_thread); - - new_pc = read_pc (); - if (new_pc != old_pc /* If at same pc, no need */ - && breakpoint_here_p (new_pc)) - { - /* User hasn't deleted the BP. - Return TRUE, finishing switch to "old_thread". */ - flush_cached_frames (); - registers_changed (); - #if 0 - printf ("---> PREPARE_TO_PROCEED (was %d, now %d)!\n", - current_thread, PIDGET (inferior_ptid)); - #endif - - return 1; - } - - /* Otherwise switch back to the user-chosen thread. */ - inferior_ptid = pid_to_ptid (current_thread); - new_pc = read_pc (); /* Re-prime register cache */ - } - - return 0; - } - #endif /* PREPARE_TO_PROCEED */ - void hppa_skip_permanent_breakpoint (void) { --- 4673,4678 ---- --JgQwtEuHJzHdouWu--