Re: Need Help for bringing m68k-based bdm target-patches form gdb-5.2.1 to gdb-5.3

[Andrew Cagney <ac131313@redhat.com>]

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