Re: H8300 Patch - Fix GDB crash problem when object file of differentH8 cpu is loaded

[Michael Snyder <msnyder at redhat dot com>]

Dhananjay R. Deshpande wrote:
> Hi Michael,
>
>
> > I'm afraid you need to un-commit it.  This breaks gdb.
> > It no longer works with the simulator for h8s, h8h, or h8sx.
>
>
> I did make sure that GDB is working with simulator for H8/300, H8/300H and H8S.
> I am appending the gdb log where output file of each target is loaded in GDB
> with simulator as target.

Well that's weird -- we must be doing something differently.
I am definitely seeing it fail.

When I build the testcase "movw.s" for "h", "s", or "sx" machine,
and then debug it like this:

	% sh-elf-gdb -nw movw.s.x
	(gdb) target sim
	(gdb) load

I find that GDB knows the target is h8300h (or whatever),
but sim does not.  None of the sim "mode" variables is ever set.


> > As I mentioned earlier in this thread, these global variables
> > that you've replaced are shared between gdb and the sim.  The
> > sim depends on them.  You've split them into essentially
> > gdb's copy and the sim's copy, but now the sim's copy is
> > never getting initialized, becuase it was gdb that
> > initialized the shared ones.  That's why they were shared.
>
>
> The SIM sets these variables in set_h8300h called from sim_load. The GDB calls sim_load.

Ah.  Well, sim_load fails.  GDB does not send a bfd pointer,
it only sends the path to the executable file.  Since "abfd"
is null, sim_load tries to open the file with the following call:

  if (abfd != NULL)
    prog_bfd = abfd;
  else
    prog_bfd = bfd_openr (prog, "coff-h8300");

Note the "coff-h8300" parameter.  Since the file isn't coff,
this call returns NULL, and therefore set_h8300h is never
called.



> If you still think that patch should be reverted, I will do that.

Well, I'd like to know what you are doing differently
that makes it work for you, but then I'd like to see
the problem where it fails to work addressed.

By the way -- the symptom for "not working" is that
GDB and SIM disagree about the size of registers,
specifically the PC.  GDB thinks the PC is 4 bytes,
but SIM thinks it is 2 bytes.  Therefore when we
hit a breakpoint at, say, 0x1000, the register value
gets displaced by 16 bits, and comes back as 0x10000000.