From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2597 invoked by alias); 6 Aug 2003 22:17:21 -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 2589 invoked from network); 6 Aug 2003 22:17:19 -0000 Received: from unknown (HELO mail.inka.de) (193.197.184.2) by sources.redhat.com with SMTP; 6 Aug 2003 22:17:19 -0000 Received: from raven.inka.de (uucp@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 19kWas-000620-00; Thu, 07 Aug 2003 00:17:18 +0200 Received: from localhost (localhost [127.0.0.1]) by raven.inka.de (Postfix) with ESMTP id 8B9761AB; Thu, 7 Aug 2003 00:16:42 +0200 (CEST) Received: by raven.inka.de (Postfix, from userid 500) id 289FF1C2; Thu, 7 Aug 2003 00:16:42 +0200 (CEST) Date: Wed, 06 Aug 2003 22:17:00 -0000 From: Josef Wolf To: Andrew Cagney Cc: schwab@suse.de, gdb@sources.redhat.com Subject: Re: Need Help for bringing m68k-based bdm target-patches form gdb-5.2.1 to gdb-5.3 Message-ID: <20030806221642.GB3349@raven.inka.de> References: <20030731223514.GD20282@raven.inka.de> <3F312844.9000308@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F312844.9000308@redhat.com> User-Agent: Mutt/1.4i X-Virus-Scanned: by AMaViS snapshot-20020531 X-SW-Source: 2003-08/txt/msg00085.txt.bz2 On Wed, Aug 06, 2003 at 12:09:40PM -0400, Andrew Cagney wrote: Thanks for your reply, Andrew! > >The problem with this replacement was that default_get_saved_register() > >semantically did > > > > if (frame==NULL) > > *addrp=REGISTER_BYTE(regnum); > > > >while generic_unwind_get_saved_register() semantically did > > > > if (frame==NULL) > > *addrp=0; > > Yes, your analysis here is correct. I believe it's been fixed in > current sources though. It is present in gdb-5.3. AFAICS, most of the targets are already using or are beeing moved to use generic_unwind_get_saved_register(). How coud this bug exist for more than a year and noone noticed? > Both frame.c:frame_register and > sentinel-frame.c:sentinel_frame_prev_register correctly are setting the > register's offset. You are talking about current (pre-6.0) code? Both functions don't exist in 5.3. > (and GDB is desperatly wants to eliminate that hack). Could you please activate verbose mode? Honestly, I did not get what you try to say here. Do you want to eliminate generic_unwind_get_saved_register or frame_register/sentinel_frame_prev_register? [ ... ] > [I'm guessing here] > > The bdm code should use supply_register(REGNUM, BUF). OK, this is what it does. > If it is still > using the [deprecated_]registers array then it will first need to be > updated so that it instead uses supply_register / collect_register. It uses supply_register but not collect_register. This looks strange to me, I would have expected that both would be used. > With that done, the code's dependency on the raw register buffer layout > should have been eliminated. That should in turn make it possible to > add these new registers to the end (instead of the middle) of the > register.table. OK, I'll try it. > The question then becomes one of should they be included by default. > For the answer to that, ask Andreas Schwab [To:ed] who is the linux m68k > maintainer. >From Andreas' mail I deduced that it doesn't make much sense to include them at all. So I am considering to throw them into the bit-bucket. OTOH, I think at least vbr/usp/ssp/sfc/dfc should be included in the generic m68k code. I still don't understand why they are not supported. After all, every m68k based cpu that is worth to be used has those registers. > >The second problem is that I have disabled the MULTI_ARCH configuration. > >If I understand correctly, you gdb-gurus want to go towards MULTI_ARCH. > >So it would be silly if I would not try to go along with you into the > >MULTI_ARCH direction. But I must confess that I have no clue what the > >requirements are for that. > The ability to disable multi-arch is about to be deleted from current > sources. Yes you'll have a problem. This is exaclty the answer that I expected :-) But then, what needs to be done to bring a new/existing target towards the MULTI_ARCH world? > >Currently, I can successfully build and run cvs snapshot from 2002-07-09. > >AFAICS, frame handling changed very much from 2002-07-09 up to gdb-5.3. > >So I expect a lot of additional hurdles on this way. And I am not sure > >whether I will be able to take those hurdles without some helping hand. > >So please, if anybody can give me some hints, they will be welcome :) > > The current m68k sources are very up-to-date so hopefully the only > problems you encounter are restricted to bdm. It turned out that 5.3 branched off before the changes I was afraid of appeared on the trunk. But this doesn't solve my problem, it just delays it to gdb-6.0 :-) Thanks! -- Please visit and sign http://petition-eurolinux.org and http://www.ffii.org -- Josef Wolf -- jw@raven.inka.de --