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

[Josef Wolf <jw@raven.inka.de>]

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 --