From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27508 invoked by alias); 9 Aug 2003 14:31:23 -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 27501 invoked from network); 9 Aug 2003 14:31:22 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 9 Aug 2003 14:31:22 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7F7BA2B7F; Sat, 9 Aug 2003 10:31:14 -0400 (EDT) Message-ID: <3F3505B2.9040104@redhat.com> Date: Sat, 09 Aug 2003 14:31: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: Josef Wolf 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 References: <20030731223514.GD20282@raven.inka.de> <3F312844.9000308@redhat.com> <20030806221642.GB3349@raven.inka.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-08/txt/msg00121.txt.bz2 Do you have a a copyright ssignment/disclaimer, and do you know who owns the code you're working on - can it be contributed to the FSF? > On Wed, Aug 06, 2003 at 12:09:40PM -0400, Andrew Cagney wrote: > 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? The method register_offset_hack, and the way GDB assumes that a value's location can be described by an offset into a register buffer. This isn't sufficient. A value may be in multiple registers. > 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? It was noticed and fixed in the mainline, and a test case was added. From memory, the problem only appears when modifying the target, and people only do that occasionally. >> [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. collect_register was a relatively recent addition to GDB. >> 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. It's reasonable to add an embedded architecture variant but not as the default. Study targets like m68hc11 which support cpu variants. Andrew