From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27163 invoked by alias); 5 Jul 2004 02:11:22 -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 27125 invoked from network); 5 Jul 2004 02:11:10 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org with SMTP; 5 Jul 2004 02:11:10 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 9D1C647D8D; Sun, 4 Jul 2004 19:11:09 -0700 (PDT) Date: Mon, 05 Jul 2004 02:11:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: Re: RFC on how to implement something between solib-irix and procfs Message-ID: <20040705021109.GA1002@gnat.com> References: <20040704192518.GD1148@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040704192518.GD1148@gnat.com> User-Agent: Mutt/1.4i X-SW-Source: 2004-07/txt/msg00032.txt.bz2 > My question is: Where should I put the code: I need to do some procfs > operations from solib-irix. I was thinking of having all the code doing > the procfs stuff inside procfs.c, and call that code from solib-irix.c > until I get the __dbx_lin() address. But at the same, it seems to me > that solib-irix.c is a target-dependent file, while procfs.c is > host-dependent. So it is not impossible that a cross-debugger be built, > making my procfs operations unavailable (assuming I can link, which is > not guarantied either). I think I found an approach that should work (untested): 1. Add some code in procfs_init_inferior some code that will add syssgi() syscall exit notification (#ifdef SYS_syssgi). The idea is that, when irix_solib_create_inferior_hook() does the target_resume(), the SYS_syssgi exit notification have already been setup automatically iff appropriate (ie iff procfs is the target). So when this routines does the target_resume, either: + We don't use procfs, and we'll just hit our entry point breakpoint. Oh well, we're just in the same situation as we have always been. Nothing's changed, so we do as we have done in the past. + Or, we use procfs, in which case the inferior will stop on the first syssgi() call exit event before our entry point. We will now suppose that we use procfs. So after we have resumed the inferior, it stopped on the first SYS_syssgi exit event. 2. I will add some code in procfs_wait() to detect such events, and do the following: + Search the text regions for __dbx_link. + If found, then: - Insert a breakpoint there - Remove SYS_syssgi() exit notifications. + resume the target and start over (goto wait_again). The intent is to put the procfs_wait() routine into a wait until we can find the routine we're looking for. As soon as this is done, then insert the breakpoint, and continue. This is all transparent to solib-irix.c. 3. Add some code again in procfs_wait() to detect when we reach the breakpoint that we just inserted (by detecting breakpoint events occurring at the address where the brekapoint was inserted). Remove the breakpoint before returning from the function. At this point, the control eventually returns to irix_solib_create_inferior_hook(), which knows we just stopped on a breakpoint. Up to now, it checks that we landed where it inserted its own breakpoint (at the entry point), but this is no longer a valid assertion, as we may have landed in __dbx_link() instead. 4. So I'll remove the check in solib-irix.c:disable_break(). After that, irix_solib_create_inferior_hook() is just free to load the symbols of all shared libraries as usual, and continue as before. The last bit that's left to do is to answer the following question: What if the inferior does *not* use shared libraries. If you follow the algorithm above, you'll find that GDB will never detect __dbx_link and therefore will never remove the SYS_syssgi exit notification. Each time the inferior makes a call to syssgi(), we'll end up stopping the inferior, checking all the text memory regions, and then restarting the inferior. To avoid this, I will modify procfs_create_inferior() to remove the SYS_syssgi exit notification after the call to fork_inferior. Sounds OK? -- Joel