From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9421 invoked by alias); 17 Dec 2003 19:32:08 -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 9409 invoked from network); 17 Dec 2003 19:32:07 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 17 Dec 2003 19:32:07 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id hBHJW6A09670 for ; Wed, 17 Dec 2003 14:32:06 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id hBHJVxM23735; Wed, 17 Dec 2003 14:31:59 -0500 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id hBHJVuO23652; Wed, 17 Dec 2003 11:31:56 -0800 Message-ID: <3FE0AF2C.8020407@redhat.com> Date: Wed, 17 Dec 2003 19:32:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 MIME-Version: 1.0 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 References: <69595093233BB547BB70CF5E492B63F2034027F3@sohm.kpit.com> In-Reply-To: <69595093233BB547BB70CF5E492B63F2034027F3@sohm.kpit.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-12/txt/msg00412.txt.bz2 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.