From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22234 invoked by alias); 17 Dec 2003 05:59:34 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22213 invoked from network); 17 Dec 2003 05:59:31 -0000 Received: from unknown (HELO sohm.kpit.com) (203.129.230.82) by sources.redhat.com with SMTP; 17 Dec 2003 05:59:31 -0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: H8300 Patch - Fix GDB crash problem when object file of different H8 cpu is loaded Date: Wed, 17 Dec 2003 05:59:00 -0000 Message-ID: <69595093233BB547BB70CF5E492B63F2034027F3@sohm.kpit.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Dhananjay R. Deshpande" To: "Michael Snyder" Cc: "Andrew Cagney" , "Andrew Cagney" , X-SW-Source: 2003-12/txt/msg00402.txt.bz2 Hi Michael, >=20 > 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 GD= B with simulator as target. >=20 > 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. >=20 The SIM sets these variables in set_h8300h called from sim_load. The GDB ca= lls sim_load. =20 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 condition= s. 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=3Di686-pc-linux-gnu --target=3Dh8300-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 >=20 >=20 > Dhananjay R. Deshpande wrote: > > Thanks. > >=20 > > Commited. >=20 > I'm afraid you need to un-commit it. This breaks gdb. > It no longer works with the simulator for h8s, h8h, or h8sx. >=20 > 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. >=20 > To complete this job, you need to work out an interface > that will allow the sim to get this information from gdb. >=20 > >=20 > > -Dhannajay > >=20 > >=20 > >>-----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=20 > >> > >>problem is not yet solved. I had put a request to update my=20 > >>public key to overseers but its not done.=20 > >>http://sources.redhat.com/ml/overseers/2003-q4/msg00240.html > >> > >>Michael, can you please handle this. > >> > >>Andrew > >> > >> > >=20 > >=20 > >=20 >=20 >=20 >=20