This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: write_register_bytes() confusion
- From: Andrew Cagney <ac131313 at ges dot redhat dot com>
- To: "Aaron J. Grier" <aaron at frye dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 01 Jul 2002 18:13:03 -0400
- Subject: Re: write_register_bytes() confusion
- References: <20020701122039.Q12218@aaron.internal>
I'm in the middle of bringing BDM for m68k support into current gdb, and
while I have fixed the most blatant calling convention changes (pid
changing to pid_t, etc) write_register_bytes() in regcache has got me
horribly confused.
(BDM being a target (or backend) to GDB.)
not to mention all this m68k craziness happening elsewhere. ;)
in v1.61 of valops.c (which appears to be current) there is the snippet:
write_register_bytes (VALUE_ADDRESS (toval) + VALUE_OFFSET (toval),
VALUE_CONTENTS (fromval), TYPE_LENGTH (type));
I'm writing a register -- it seems in my case this should be:
write_register_bytes (VALUE_REGNO (toval), VALUE_CONTENTS (fromval), 1);
the 1 of course is machine dependent
The above code behaves as per the designers intent. The ADDRESS is an
offset into registers[] array.
However, GDB is trying to move away from that mechanism and more towards
something like what you describe.
what I'm seeing is the register number getting completely thrashed on
the way through.
yet all calls to write_register_bytes are using VALUE_ADDRESS?
insane. I'm starting to think I need to back off -current and just
stick with gdb-5.0...
An up-to-date target backend should only be using:
supply_register()
regcache_collect()
it should not contain code that refers to registers[].
enjoy,
Andrew