This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]