This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Need Help for bringing m68k-based bdm target-patches form gdb-5.2.1 to gdb-5.3
- From: Josef Wolf <jw at raven dot inka dot de>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: schwab at suse dot de, gdb at sources dot redhat dot com
- Date: Thu, 7 Aug 2003 00:16:42 +0200
- 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>
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 --