RE: H8300 Patch - Fix GDB crash problem when object file of different H8 cpu is loaded

["Dhananjay R. Deshpande" <dhananjayd@KPITCummins.com>]

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.

> 
> 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.
 
If you still think that patch should be reverted, I will do that.

[dhananjayd@Linuxsrv5 gnu]$ ~/gdbh8/bin/h8300-elf-gdb
GNU gdb 2003-12-17-cvs
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=h8300-elf".
(gdb) file h8.out
Reading symbols from h8.out...done.
(gdb) target sim
Connected to the simulator.
(gdb) lo
Loading section .init, size 0xa vma 0x100
Loading section .text, size 0xab82 vma 0x10c
Loading section .fini, size 0x6 vma 0xac8e
Loading section .rodata, size 0x30c vma 0xac94
Loading section .data, size 0x41a vma 0xafa0
Loading section .ctors, size 0x4 vma 0xb3ba
Loading section .dtors, size 0x4 vma 0xb3be
Loading section .jcr, size 0x2 vma 0xb3c2
Start address 0x10c
Transfer rate: 366096 bits in <1 sec.
(gdb) r
Starting program: /user/dhananjayd/gnu/h8.out
Hello 1,2,3

Program exited normally.
(gdb) show architecture
The target architecture is set automatically (currently h8300)
(gdb) file h8h.out
A program is being debugged already.  Kill it? (y or n) y

Load new symbol table from "h8h.out"? (y or n) y
Reading symbols from h8h.out...done.
(gdb) target sim
Connected to the simulator.
(gdb) lo
Loading section .init, size 0xa vma 0x100
Loading section .text, size 0x9052 vma 0x10c
Loading section .fini, size 0x6 vma 0x915e
Loading section .rodata, size 0x3e0 vma 0x9164
Loading section .data, size 0x754 vma 0x9544
Loading section .ctors, size 0x8 vma 0x9c98
Loading section .dtors, size 0x8 vma 0x9ca0
Loading section .jcr, size 0x4 vma 0x9ca8
Start address 0x10c
Transfer rate: 318800 bits in <1 sec.
(gdb) r
Starting program: /user/dhananjayd/gnu/h8h.out
Hello 1,2,3

Program exited normally.
(gdb) show architecture
The target architecture is set automatically (currently h8300h)
(gdb) file h8s.out
A program is being debugged already.  Kill it? (y or n) y

Load new symbol table from "h8s.out"? (y or n) y
Reading symbols from h8s.out...done.
(gdb) target sim
Connected to the simulator.
(gdb) lo
Loading section .init, size 0xa vma 0x100
Loading section .text, size 0x8df0 vma 0x10c
Loading section .fini, size 0x6 vma 0x8efc
Loading section .rodata, size 0x3e0 vma 0x8f04
Loading section .data, size 0x754 vma 0x92e4
Loading section .ctors, size 0x8 vma 0x9a38
Loading section .dtors, size 0x8 vma 0x9a40
Loading section .jcr, size 0x4 vma 0x9a48
Start address 0x10c
Transfer rate: 313920 bits in <1 sec.
(gdb) r
Starting program: /user/dhananjayd/gnu/h8s.out
Hello 1,2,3

Program exited normally.
(gdb) show architecture
The target architecture is set automatically (currently h8300s)
(gdb)


Regards,
Dhananjay

> -----Original Message-----
> From: Michael Snyder [mailto:msnyder@redhat.com]
> Sent: Wednesday, December 17, 2003 5:27 AM
> To: Dhananjay R. Deshpande
> Cc: Andrew Cagney; Andrew Cagney; gdb-patches@sources.redhat.com
> Subject: Re: H8300 Patch - Fix GDB crash problem when object file of
> different H8 cpu is loaded
> 
> 
> Dhananjay R. Deshpande wrote:
> > Thanks.
> > 
> > Commited.
> 
> I'm afraid you need to un-commit it.  This breaks gdb.
> It no longer works with the simulator for h8s, h8h, or h8sx.
> 
> 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.
> 
> To complete this job, you need to work out an interface
> that will allow the sim to get this information from gdb.
> 
> > 
> > -Dhannajay
> > 
> > 
> >>-----Original Message-----
> >>From: Andrew Cagney [mailto:cagney@gnu.org]
> >>Sent: Wednesday, December 10, 2003 10:41 PM
> >>To: Dhananjay R. Deshpande; Michael Snyder
> >>Cc: Andrew Cagney; gdb-patches@sources.redhat.com
> >>Subject: Re: H8300 Patch - Fix GDB crash problem when object file of
> >>different H8 cpu is loaded
> >>
> >>
> >>
> >>>Hi,
> >>>
> >>>If you can, please check in the patch. My CVS access 
> >>
> >>problem is not yet solved. I had put a request to update my 
> >>public key to overseers but its not done. 
> >>http://sources.redhat.com/ml/overseers/2003-q4/msg00240.html
> >>
> >>Michael, can you please handle this.
> >>
> >>Andrew
> >>
> >>
> > 
> > 
> > 
> 
> 
>