RE: [PATCH] Fix problem with sim_load (h8300)

RE: [PATCH] Fix problem with sim_load (h8300)

[Dhananjay R. Deshpande]

ping..

This patch isn't checked in.

-Dhananjay

> -----Original Message-----
> From: Dhananjay R. Deshpande 
> Sent: Thursday, December 18, 2003 11:20 AM
> To: 'Michael Snyder'
> Cc: gdb-patches@sources.redhat.com
> Subject: RE: [PATCH] Fix problem with sim_load (h8300)
> 
> 
> Hi Michael,
> 
> For convenience I use h8300-elf-gdb built with 
> --enable-tragets=h8300-coff. This way I can debug/test both 
> coff and elf objects. Because of this bfd recognizes 
> "coff-h8300" format although binary is in elf32-h8300 format 
> and it worked for me. 
> 
> The patch works fine for elf only build. Please check it in.
> 
> Regards,
> Dhananjay
> 
> > -----Original Message-----
> > From: Michael Snyder [mailto:msnyder@redhat.com]
> > Sent: Thursday, December 18, 2003 1:25 AM
> > To: Dhananjay R. Deshpande
> > Cc: gdb-patches@sources.redhat.com
> > Subject: [PATCH] Fix problem with sim_load (h8300)
> > 
> > 
> > 
> > Dhananjay, this seems to fix the problem.  I discovered that
> > in most cases people don't pass a specific bfd-target to bfd_openr.
> > They just let bfd figure out which target to use.
> > 
> > I'll give you a chance to try this out before I check it in.
> > 
> > Michael
> > 
> > 
> 

Re: [PATCH] Fix problem with sim_load (h8300)

[Michael Snyder]

Dhananjay R. Deshpande wrote:
> ping..
> 
> This patch isn't checked in.

Committed.

RE: [PATCH] Fix problem with sim_load (h8300)

[Dhananjay R. Deshpande]

Hi Michael,

For convenience I use h8300-elf-gdb built with --enable-tragets=h8300-coff. This way I can debug/test both coff and elf objects. Because of this bfd recognizes "coff-h8300" format although binary is in elf32-h8300 format and it worked for me. 

The patch works fine for elf only build. Please check it in.

Regards,
Dhananjay

> -----Original Message-----
> From: Michael Snyder [mailto:msnyder@redhat.com]
> Sent: Thursday, December 18, 2003 1:25 AM
> To: Dhananjay R. Deshpande
> Cc: gdb-patches@sources.redhat.com
> Subject: [PATCH] Fix problem with sim_load (h8300)
> 
> 
> 
> Dhananjay, this seems to fix the problem.  I discovered that
> in most cases people don't pass a specific bfd-target to bfd_openr.
> They just let bfd figure out which target to use.
> 
> I'll give you a chance to try this out before I check it in.
> 
> Michael
> 
> 

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

[Dhananjay R. Deshpande]

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
> >>
> >>
> > 
> > 
> > 
> 
> 
> 

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

[Michael Snyder]

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.

[PATCH] Fix problem with sim_load (h8300)

[Michael Snyder]

[-- Attachment #1: Type: text/plain, Size: 252 bytes --]


Dhananjay, this seems to fix the problem.  I discovered that
in most cases people don't pass a specific bfd-target to bfd_openr.
They just let bfd figure out which target to use.

I'll give you a chance to try this out before I check it in.

Michael


[-- Attachment #2: openr --]
[-- Type: text/plain, Size: 984 bytes --]

2003-12-17  Michael Snyder  <msnyder@redhat.com>

	* compile.c (sim_load): Don't specify "coff-h8300" when
	calling bfd_openr: we use elf now, and the norm is not to 
	specify a target but to let bfd figure it out.

Index: compile.c
===================================================================
RCS file: /cvs/src/src/sim/h8300/compile.c,v
retrieving revision 1.38
diff -p -r1.38 compile.c
*** compile.c	11 Dec 2003 06:21:12 -0000	1.38
--- compile.c	17 Dec 2003 19:49:33 -0000
*************** sim_load (SIM_DESC sd, char *prog, bfd *
*** 5052,5058 ****
    if (abfd != NULL)
      prog_bfd = abfd;
    else
!     prog_bfd = bfd_openr (prog, "coff-h8300");
    if (prog_bfd != NULL)
      {
        /* Set the cpu type.  We ignore failure from bfd_check_format
--- 5052,5058 ----
    if (abfd != NULL)
      prog_bfd = abfd;
    else
!     prog_bfd = bfd_openr (prog, NULL);
    if (prog_bfd != NULL)
      {
        /* Set the cpu type.  We ignore failure from bfd_check_format