From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23126 invoked by alias); 12 Jun 2003 17:00:18 -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 23068 invoked from network); 12 Jun 2003 17:00:16 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 12 Jun 2003 17:00:16 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3BF322B63; Thu, 12 Jun 2003 13:00:13 -0400 (EDT) Message-ID: <3EE8B19D.5040502@redhat.com> Date: Thu, 12 Jun 2003 17:00:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb@sources.redhat.com, Corinna Vinschen Subject: Re: HOWTO move a target from old style multiarched to new style multiarched? References: <20030611120212.GB30116@cygbert.vinschen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00207.txt.bz2 > Hi, > > there were a lot of changes in the last couple of months to convert gdb > to a new way of doing things. That's probably good but I don't know how > many people actually understand the whole process. I must admit, I don't. This was my most recent guess: http://sources.redhat.com/ml/gdb/2003-05/msg00399.html Briefly, slow eliminate each set_gdbarch_deprecated* call, the rest will follow. > I'm under the impression the documentation is missing an important part. > There's some sort of description spread over the source code now but it > doesn't give a coherent picture and I also didn't find that in the docs. There isn't a single picture as there isn't a single change. Instead there are three largely independant changes: - frames (the obvious one) - inferior function calls - global buffer -> regcache or frame > Wouldn't it be possible to write a HOWTO for the poor developer soul, > who's left behind with a target with now using 80% deprecated functions? > IMHO, that HOWTO written by somebody who knows what's going on could > tells us To speak personally, I think it is dangerous for someone to post a HOWTO on something they haven't done :-/ I, for instance, have only done the d10v and there my only recommendation is to not follow my lead. I have posted several theoretical guidelines but there, it's strictly conjecture, and the suggestions haven't received any feedback. Contrast this to multi-arch where the process was documented after I'd done several [partial] multi-arch conversions -> I knew it worked. Anyway, here is an expansion of the last post: for method in set_gdbarch_deprecated* do look in gdbarch.sh to see if there is a direct replacement ex: UNWIND_SP is a direct replacement for TARGET_READ_SP look in the d10v for an example (this should be pretty obvious, replace A with B) for method in set_gdbarch_deprecated* do look in gdbarch.sh to see if it is a dummy-frame related function ex: The dummy call frame SP should be set by push_dummy_call ex: This is simply not needed. ... move, implement, or delete the relevant code cut a USER_CPU_frame branch - implement a traditional unwinder so that the basics are working - implement additional unwinders for sigtramps and the like - replace the lot But remember, I don't know if this process works, I've not tried it. As for doco, the bit I acknowledge is missing is an architectural overview of the frame code. The regcache does have posted doco: http://sources.redhat.com/ml/gdb/2002-07/msg00202.html Andrew > The datastructure `struct bits' is replaced by `struct pieces'. > This requires to use a new set of functions... > > Create functions foo(), bar() and baz(), doing... > > If you use function new_and_shiny() you must also replace > old_and_dirty(), otherwise... > > The functions old() and cruft() are replaced by glitter() which > returns yadda... > > Function ugly() is not used anymore and can be removed without > substitution... > > and so on. That would be very helpful and probably speed up the > conversion of targets to "new style" enormously. > > Or did I just miss the documentation on this? > > Corinna > > -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen@redhat.com