From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21489 invoked by alias); 3 Apr 2004 21:06:18 -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 21481 invoked from network); 3 Apr 2004 21:06:17 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 3 Apr 2004 21:06:17 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i33L6Gjl015685 for ; Sat, 3 Apr 2004 16:06:16 -0500 Received: from zenia.home.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i33L6Dj08618; Sat, 3 Apr 2004 16:06:14 -0500 To: Kevin Buettner Cc: gdb-patches@sources.redhat.com, Joel Brobecker Subject: Re: [RFA] Fix small problems in rs6000-tdep.c:skip_prologue() References: <20040402183637.GC871@gnat.com> <20040403071726.60159025@saguaro> From: Jim Blandy Date: Sat, 03 Apr 2004 21:06:00 -0000 In-Reply-To: <20040403071726.60159025@saguaro> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-04/txt/msg00102.txt.bz2 Kevin Buettner writes: > > In this case, the stX 0,N(31) is spilling an argument, even though r0 > > is not an argument register. ('evstdd' is an E500 instruction that > > is definitely an argument spill.) > > Do you have any idea why the compiler chose to arrange the code this way? > Why couldn't it have just done "stb 3, 8(31)" and ommitted the "mr 0, 3" > altogether? I have no idea. My attitude has always been that we just have to put up with whatever junk we get. GDB, by its nature, just has to cope with whatever hair the upstream implementors come up with. > > Clearly, both your function and mine need to go into the test suite... > > > > What if we did something like this? It'd need to be combined with the > > rest of your change, I'm just sketching: > > > > *** rs6000-tdep.c.~1.191.~ 2004-03-29 16:45:15.000000000 -0500 > > --- rs6000-tdep.c 2004-04-02 16:11:26.000000000 -0500 > > *************** > > *** 441,446 **** > > --- 441,447 ---- > > int minimal_toc_loaded = 0; > > int prev_insn_was_prologue_insn = 1; > > int num_skip_non_prologue_insns = 0; > > + int r0_contains_argument = 0; > > const struct bfd_arch_info *arch_info = gdbarch_bfd_arch_info (current_gdbarch); > > struct gdbarch_tdep *tdep = gdbarch_tdep (current_gdbarch); > > > > *************** > > *** 509,519 **** > > --- 510,524 ---- > > ones. */ > > if (lr_reg < 0) > > lr_reg = (op & 0x03e00000); > > + if (lr_reg == 0) > > + r0_contains_argument = 0; > > This special casing of r0 bothers me. In your example above, what's to > prevent the compiler from using some other scratch register, e.g. r11 or > r12? If it starts doing so, do we add more state variables to record this > fact? I guess so. For what it's worth --- the analysis used in s390-tdep.c makes all these problems just go away; it is able to recognize argument spills, register saves, etc. done in almost any reasonable fashion. Internal to Red Hat, I've gotten the architecture-independent portions split out; the arch-dependent code that's left over is pretty much just an interpreter for prologue instructions. In spare moments I've been trying to put together enough platforms for PPC testing (Altivec! E500! AIX! Embedded ABI! Rah rah rah.) that this could be approached with some sort of confidence.