From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5899 invoked by alias); 23 Nov 2005 03:09:48 -0000 Received: (qmail 5891 invoked by uid 22791); 23 Nov 2005 03:09:47 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 23 Nov 2005 03:09:46 +0000 Received: by zproxy.gmail.com with SMTP id x3so1290339nzd for ; Tue, 22 Nov 2005 19:09:44 -0800 (PST) Received: by 10.37.20.27 with SMTP id x27mr4515064nzi; Tue, 22 Nov 2005 19:09:44 -0800 (PST) Received: by 10.37.2.35 with HTTP; Tue, 22 Nov 2005 19:09:44 -0800 (PST) Message-ID: <8f2776cb0511221909i2fe80536oed9a1617700515ae@mail.gmail.com> Date: Wed, 23 Nov 2005 03:14:00 -0000 From: Jim Blandy To: gdb@sourceware.org Subject: Re: Prologue analysis interface In-Reply-To: <20051123020455.GA2247@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <8f2776cb0511221124u988f759u17418a114e1f3b7c@mail.gmail.com> <20051122193034.GA25326@nevyn.them.org> <8f2776cb0511221549p2cfbbc30w621da6c2f159a33f@mail.gmail.com> <20051123020455.GA2247@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00517.txt.bz2 On 11/22/05, Daniel Jacobowitz wrote: > One thing that jumped out at me in the m32c analyzer. You record > pushes of registers as frame related, and you record spills of argument > registers using "mov" as frame related. You mean "not frame related" right? Yes, it does undermine the general principle. I don't really see why stores of original values to the stack would be any worse. > The question in my mind is whether the target-independently-describable > tweaks we need for this are good for all targets. And as unlikely as > it may seem, I think it's true. For instance, S/390 has a bit to use > only the stack slot with the highest address if it sees multiple saves. > We could easily enough handle that in the target-dependent part in the > model I described above, but we don't have to (with an appropriate > check for the direction of the stack). It's probably good just about > everywhere. I see how the m32c and the S/390 could both be accomodated by a single piece of code. But I think there's something to watch out for here.=20 We don't want the generic prologue analyzer driver to become a somewhat complex piece of code with a lot of little behaviors carefully chosen to make things work nicely on particular targets --- exactly what you're suggesting. Think about (if I'm remembering correctly) monitor_fetch_register. It's a generic function, meant to be shared amongst all sorts of monitors, that does a decent job groveling through the output of a ROM monitor's "show me the registers" commands and finding the actual values. When it works, it's great, but when it isn't working right for your monitor, you just have to custom-code your own register parser. You can't change the generic function's behavior in the slightest, because you don't know what behaviors all the other monitors (which you can't test) are depending on. Which puts you in the ridiculous situation of not being able to change monitor_fetch_register even if *nobody* wants the current behavior --- because you can't discover that that's the case.=20 It's an ossified function. It will never change. That's not the end of the world --- you just copy it, install it as a custom function in the monitor_ops structure, and go on your way. But you lose the benefits you'd like to get from common code. > Both the S/390 and m32c use heuristics to terminate the frame chain. > I agree that these are necessary, but I've also come to see a bit of > the counterargument that they're in the wrong place. I think what we > need may be an additional method for frames to say "this same unwinder > thinks the stack is finished here". Pathological examples: calling > thread_start() or an optimized noreturn function from gdb. Why is it better to have a separate method than to have 'this_id' leave the id unchanged? > So, for now, how about that? Just provide something along the lines of > the tramp-frame interface that does the busywork. We can adjust later > what is busywork and what isn't. Having voiced my misgivings above, I'll give it a shot.