From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23997 invoked by alias); 31 Mar 2003 22:32:20 -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 23955 invoked from network); 31 Mar 2003 22:32:19 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (209.53.16.215) by sources.redhat.com with SMTP; 31 Mar 2003 22:32:19 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 98999D34B8; Mon, 31 Mar 2003 14:32:13 -0800 (PST) Date: Mon, 31 Mar 2003 22:32:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: [6] What if EXTRA_FRAME_INFO wasn't required Message-ID: <20030331223213.GF916@gnat.com> References: <3E84BFD5.3080304@redhat.com> <20030328213935.GZ924@gnat.com> <3E878942.3000700@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E878942.3000700@redhat.com> User-Agent: Mutt/1.4i X-SW-Source: 2003-03/txt/msg00425.txt.bz2 > The attached appears to drag HP, kicking and screaming, into multi-arch > partial. It isn't a ``get out of goal free card'' though. HP/UX needs > to leap-frog all the init frame stuff and start using the latest frame > code. Otherwize it will just be deleted for relying on deprecated > mechanisms. > > I also don't know if it actually works. Will try it out. I also identified a few macros that were not converted yet, but all of them should be easy to do, except one (FIX_CALL_DUMMY) which I understand should be replaced in the relatively near future. Can I commit your patch if it turns out to be working, or would you prefer to do it? Thanks, -- Joel BTW: The next steps in the plan, once HP/UX is multiarch partial, is to shuffle a bit all the declarations in tm-hppa.h to put them either in a hppa-tdep.h file, or even hppa-tdep.c if possible. This should help us reduce the size of tm-hppa.h, and pave the way to its eventual deletion. Next will be the multi-arching of hppa64, which I hope will be a reasonably small task, given that hppa is already done. Then I will look at getting rid of the deprecated mechanisms. Next (if I'm not dead by then :-) will be to have a look at these HP-specific macros they added. Maybe I'll even look at them before working on the use of deprecated functions.