From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24633 invoked by alias); 26 Mar 2003 13:55:01 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 24625 invoked from network); 26 Mar 2003 13:55:00 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 26 Mar 2003 13:55:00 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h2QDt0Q25923 for ; Wed, 26 Mar 2003 08:55:00 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h2QDsxQ31415 for ; Wed, 26 Mar 2003 08:54:59 -0500 Received: from cygbert.vinschen.de (vpn50-16.rdu.redhat.com [172.16.50.16]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h2QDsw507915 for ; Wed, 26 Mar 2003 05:54:58 -0800 Received: (from corinna@localhost) by cygbert.vinschen.de (8.11.6/8.9.3/Linux sendmail 8.9.3) id h2QDstc08887 for gdb@sources.redhat.com; Wed, 26 Mar 2003 14:54:55 +0100 Date: Wed, 26 Mar 2003 13:55:00 -0000 From: Corinna Vinschen To: gdb@sources.redhat.com Subject: [RFC] Is inside_entry_file useful and needed? Message-ID: <20030326135455.GV23762@cygbert.vinschen.de> Reply-To: gdb@sources.redhat.com Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-SW-Source: 2003-03/txt/msg00358.txt.bz2 Hi, the reason I'm going to discuss the inside_entry_file() function is that I had trouble with the asm-source.exp tests on both platforms I currently care about, Cygwin and XStormy16, one native, one embedded target. Both targets have the same failures in the asm-source.exp tests: (gdb) FAIL: gdb.asm/asm-source.exp: bt ALL in foo2 (gdb) FAIL: gdb.asm/asm-source.exp: bt 2 in foo2 (gdb) FAIL: gdb.asm/asm-source.exp: bt 3 in foo3 (gdb) FAIL: gdb.asm/asm-source.exp: finish from foo3 (gdb) FAIL: gdb.asm/asm-source.exp: info source asmsrc2.s (gdb) FAIL: gdb.asm/asm-source.exp: info line (gdb) FAIL: gdb.asm/asm-source.exp: next over foo3 After some debugging it turned out that the cause for these failures is a misbehaving of the frame code due to the return value of inside_entry_file(). This function returns "true" for all functions implemented in asmsrc1.s for obvious reasons - the assembler test is not linked with an actual startup file like crt0.o. Due to the return code of inside_entry_file(), get_prev_frame() misbehaves in the first place. It returns NULL prematurely, no chance left to ask the target dependent code if a prev frame might exist. The second place where it goes wrong is frame_chain_valid(), called from legacy_get_prev_frame(). Here the same happens again, the inside_entry_file() function is called before the target dependent code might express another opinion about the validity of the frame chain. In the case of XStorm16, everything's ok when removing the calls to inside_entry_file(). Cygwin, on the other hand still is wrong. 5 out of these 7 error are still left on a Cygwin box. Why? Digging a bit more I found that once more inside_entry_file() was the culprit. This time in i386_frame_chain(). That function ends with: if (! inside_entry_file (get_frame_pc (frame))) return read_memory_unsigned_integer (get_frame_base (frame), 4); return 0; which invariably fails to return the correct address in the above case. For testing purposes I've changed the above three lines to just one: return read_memory_unsigned_integer (get_frame_base (frame), 4); Now everythings ok for Cygwin as well. With these three changes, both targets behave fine and no regressions are introduced in the testsuite. Q1: Is there actually a target which depends on the inside_entry_file() function? Q2: If Q1 has to be answered with "yes", I'd like to propose the introduction of a predicate which can be set by the target code to disable the inside_entry_file() function as already noted in two comments in the gdb source code: frame.c::get_prev_frame(): /* If we're inside the entry file, it isn't valid. Don't apply this test to a dummy frame - dummy frame PC's typically land in the entry file. Don't apply this test to the sentinel frame. Sentinel frames should always be allowed to unwind. */ /* NOTE: drow/2002-12-25: should there be a way to disable this check? It assumes a single small entry file, and the way some debug readers (e.g. dbxread) figure out which object is the entry file is somewhat hokey. */ /* NOTE: cagney/2003-01-10: If there is a way of disabling this test then it should probably be moved to before the ->prev_p test, above. */ blockframe.c::frame_chain_valid(): /* If we're inside the entry file, it isn't valid. */ /* NOTE/drow 2002-12-25: should there be a way to disable this check? It assumes a single small entry file, and the way some debug readers (e.g. dbxread) figure out which object is the entry file is somewhat hokey. */ Thoughts? Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen@redhat.com