Re: "Info reg doesn't work"

Re: "Info reg doesn't work"

[Jim Blandy]

"Xinan Tang" <xinan@tidalnetworks.net> writes:
>   I don't know what protocol. I use the sim target under gdb:
> 
> > target sim

Then the code in gdb/remote-sim.c would be a good thing to look at.
In particular, are the right values coming through
gdbsim_fetch_register and gdbsim_store_register?

"which function is called when updating a register?"

[Xinan Tang]

Hi

  I set breakpoints on both:

	-- gdbsim_fetch_register and
      -- gdbsim_store_register

  when single stepping the instruction execution, I noticed that
gdbsim_fetech_register was called but gdbsim_store_register.

  Which function is actually called to update a register content within gdb
using a built-in simulator?

Thanks

--Xinan
__________________________________________________
"Xinan Tang" <xinan@tidalnetworks.net> writes:
>
> > target sim

Then the code in gdb/remote-sim.c would be a good thing to look at.
In particular, are the right values coming through
gdbsim_fetch_register and gdbsim_store_register?

Re: "which function is called when updating a register?"

[Andrew Cagney]

> Hi
> 
>   I set breakpoints on both:
> 
> 	-- gdbsim_fetch_register and
>       -- gdbsim_store_register
> 
>   when single stepping the instruction execution, I noticed that
> gdbsim_fetech_register was called but gdbsim_store_register.
> 
>   Which function is actually called to update a register content within gdb
> using a built-in simulator?

GDB rarely has the need to write to the inferiors registers (if it did 
gdbsim_store_register would be called though).  Try something like:
	set $pc = 0
When the simulator is running a program it updates registers locally and 
directly.

Andrew

RE: "which function is called when updating a register?"

[Xinan Tang]

Hi

  Thanks for the reply.

  My problem is that after I building a new target, I could not see the
registers being updated except PC. For example, after I did "set $sp =
0x80001000", and then "info reg", I still saw $sp is ZERO.

  I am trying to fig out what was wrong with my build. One way to do this is
to trace the simulator execution. However I don't have a clear picture about
the interface between the simulator execution and gdb. For example, which
data structures are read by "info reg" command and which ones are touched by
the simulator. How could GDB get those register content being updated by the
simulator?

Thanks

--Xinan

-----Original Message-----
From: Andrew Cagney [mailto:cagney@gnu.org]
Sent: Sunday, July 18, 2004 11:32 AM
To: Xinan Tang
Cc: gdb@sources.redhat.com
Subject: Re: "which function is called when updating a register?"


> Hi
>
>   I set breakpoints on both:
>
> 	-- gdbsim_fetch_register and
>       -- gdbsim_store_register
>
>   when single stepping the instruction execution, I noticed that
> gdbsim_fetech_register was called but gdbsim_store_register.
>
>   Which function is actually called to update a register content within
gdb
> using a built-in simulator?

GDB rarely has the need to write to the inferiors registers (if it did
gdbsim_store_register would be called though).  Try something like:
	set $pc = 0
When the simulator is running a program it updates registers locally and
directly.

Andrew

Re: "which function is called when updating a register?"

[Andrew Cagney]

> Hi
> 
>   Thanks for the reply.
> 
>   My problem is that after I building a new target, I could not see the
> registers being updated except PC. For example, after I did "set $sp =
> 0x80001000", and then "info reg", I still saw $sp is ZERO.
> 
>   I am trying to fig out what was wrong with my build. One way to do this is
> to trace the simulator execution. However I don't have a clear picture about
> the interface between the simulator execution and gdb. For example, which
> data structures are read by "info reg" command and which ones are touched by
> the simulator. How could GDB get those register content being updated by the
> simulator?

When the inferior (simulator) is resumed, GDB flushes its internal 
register cache (target_registers_changed).  This causes GDB to always 
fetch the latest register values found in the simulator.

Andrew

"Add sim memory region by default"

[Xinan Tang]

Hi

  Rather than adding a memory region through command of

	"sim memory-region addr,length"

  I would like to add some memory regions permanently within my gdb. Which
source files need to be touched to add a new memory region in GDB?

Thanks

--Xinan

RE: "Add sim memory region by default"

[Dave Korn]

> -----Original Message-----
> From: gdb-owner On Behalf Of Xinan Tang
> Sent: 20 July 2004 23:38

>   Rather than adding a memory region through command of
> 
> 	"sim memory-region addr,length"
> 
>   I would like to add some memory regions permanently within 
> my gdb. Which
> source files need to be touched to add a new memory region in GDB?

  Why not just put a set of "sim memory-region" commands into a .gdbinit
file?  It's just as automatic and effective and a whole lot simpler and more
generic than hardcoding it into the source.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

RE: "Add sim memory region by default"

[Xinan Tang]

Hi

  That is the exact solution we have right now. However this requires each
user coping the .gdbinit file.

  I wonder whether I can hardcode this info into the GDB and do not bother
each user copying anymore.

Thanks

--Xinan

-----Original Message-----
From: Dave Korn [mailto:dk@artimi.com]
Sent: Wednesday, July 21, 2004 5:11 AM
To: 'Xinan Tang'; gdb@sources.redhat.com
Subject: RE: "Add sim memory region by default"


> -----Original Message-----
> From: gdb-owner On Behalf Of Xinan Tang
> Sent: 20 July 2004 23:38

>   Rather than adding a memory region through command of
>
> 	"sim memory-region addr,length"
>
>   I would like to add some memory regions permanently within
> my gdb. Which
> source files need to be touched to add a new memory region in GDB?

  Why not just put a set of "sim memory-region" commands into a .gdbinit
file?  It's just as automatic and effective and a whole lot simpler and more
generic than hardcoding it into the source.


    cheers,
      DaveK
--
Can't think of a witty .sigline today....

"igen based simulators doc.?"

[Xinan Tang]

Hi

  Could someone kindly point to me some reference links for understanding
igen based simulators? Especially the syntax used in igen?

  I would like to know how to add new instructions and remove some
instructions that are not supported in our new architecture?

Thanks

--Xinan

"igen vs. cgen?"

[Xinan Tang]

Hi

  When I search the gdb mailing list for adding a new simulator, two
approaches were mentioned: igen vs. cgen.

  Now igen (psim) was included within gdb, is there any consensus which one
should be used within gdb for adding a new simulator?

Thanks

--Xinan

RE: "igen vs. cgen?"

[Monika Chaddha]

Hi Xinan

Igen would be used for adding new simulator input. There are many igen
files present in the source... Mips.igen, M16.igen etc...

The source for 'igen' (the simulator generator used) is present at
'src/sim/igen'. The 'igen' simulator generator takes input the mips.igen
file which includes other igen files and generates the simulator source.


The source for simulator will generate in build directory. The contents
of this source will depend on the input 'mips.igen' file. These files
are responsible for instruction implementation.

U need new model name also to add any new instruction.

Monika


>-----Original Message-----
>From: gdb-owner@sources.redhat.com
[mailto:gdb-owner@sources.redhat.com] On
>Behalf Of Xinan Tang
>Sent: Thursday, July 22, 2004 12:46 AM
>To: gdb@sources.redhat.com
>Subject: "igen vs. cgen?"
>
>Hi
>
>  When I search the gdb mailing list for adding a new simulator, two
>approaches were mentioned: igen vs. cgen.
>
>  Now igen (psim) was included within gdb, is there any consensus which
one
>should be used within gdb for adding a new simulator?
>
>Thanks
>
>--Xinan

RE: "igen vs. cgen?"

[Xinan Tang]

Hi Monika,

  Thanks for the reply.

  Is there doc. showing any examples on how to add a new instruction or
disable some existing ones based on existing *.igen files?

  I googled the web and only found a few pages from psim online manual.
However it does not provide enough details.

Thanks

--Xinan

-----Original Message-----
From: gdb-owner@sources.redhat.com
[mailto:gdb-owner@sources.redhat.com]On Behalf Of Monika Chaddha
Sent: Wednesday, July 21, 2004 11:12 PM
To: 'Xinan Tang'
Cc: gdb@sources.redhat.com
Subject: RE: "igen vs. cgen?"


Hi Xinan

Igen would be used for adding new simulator input. There are many igen
files present in the source... Mips.igen, M16.igen etc...

The source for 'igen' (the simulator generator used) is present at
'src/sim/igen'. The 'igen' simulator generator takes input the mips.igen
file which includes other igen files and generates the simulator source.


The source for simulator will generate in build directory. The contents
of this source will depend on the input 'mips.igen' file. These files
are responsible for instruction implementation.

U need new model name also to add any new instruction.

Monika

RE: "igen vs. cgen?"

[Monika Chaddha]

Yes.... you will not find any specific document.

I can provide u some idea ... if it helps u
I'll take one example and try to explain u.

000000,5.RS,5.RT,5.RD,00000,100000:SPECIAL:32::ADD
"add r<RD>, r<RS>, r<RT>"
*mipsI:
*mipsII:
*mipsIII:
*mipsIV:
*mipsV:
*mips32:
*mips64:
*vr4100:
*vr5000:
*r3900:
{
------
------
}
The above is existing code for add instruction in mips.igen. You want
that this instruction should be supported by your architecture.

Firstly you need to change configuration files. Firstly add your
architecture based information in configure files in main directory and
sim directory

Example: /src/sim/mips/configure

For mipsisa32 the configuration information is as follows

mipsisa32*-*-*)	sim_gen=IGEN
			sim_igen_machine="-M mips32"
			sim_igen_filter="32,f"
			sim_mach_default="mipsisa32"
			;;

Here sim_gen is simulator generator
Sim_igen_machine will work as a model name ie for mipisa32 the model
name is mips32.
sim_igen_filter is size of instructions
sim_mach_defult is for bfd.

You also define ur architecture. Put yours entry wherever needed in the
configuration files.

Suppose u have defined as followes for architecture xyz

xyz*-*-*)		sim_gen=IGEN
			sim_igen_machine="-M xyz"
			sim_igen_filter="32,f"
			sim_mach_default="mipsisa32"
			;;

Also add this target name in the configuration files in the main
directory
If you want add instruction to be support by ur architecture "xyz"
Than put ur architecture name in the model list as follows

000000,5.RS,5.RT,5.RD,00000,100000:SPECIAL:32::ADD
"add r<RD>, r<RS>, r<RT>"
*mipsI:
*mipsII:
*mipsIII:
*mipsIV:
*mipsV:
*mips32:
*mips64:
*vr4100:
*vr5000:
*r3900:
*xyz: (new architecture)
{
------
------
}

Now if u build gdb for "xyz", this "ADD" instruction will be
supported.If u don't want to support this instruction ... remove ur
model name from here.


Regards
Monika
>-----Original Message-----
>From: gdb-owner@sources.redhat.com
[mailto:gdb-owner@sources.redhat.com] On
>Behalf Of Xinan Tang
>Sent: Friday, July 23, 2004 12:23 AM
>To: Monika Chaddha
>Cc: gdb@sources.redhat.com
>Subject: RE: "igen vs. cgen?"
>
>Hi Monika,
>
>  Thanks for the reply.
>
>  Is there doc. showing any examples on how to add a new instruction or
>disable some existing ones based on existing *.igen files?
>
>  I googled the web and only found a few pages from psim online manual.
>However it does not provide enough details.
>
>Thanks
>
>--Xinan
>
>-----Original Message-----
>From: gdb-owner@sources.redhat.com
>[mailto:gdb-owner@sources.redhat.com]On Behalf Of Monika Chaddha
>Sent: Wednesday, July 21, 2004 11:12 PM
>To: 'Xinan Tang'
>Cc: gdb@sources.redhat.com
>Subject: RE: "igen vs. cgen?"
>
>
>Hi Xinan
>
>Igen would be used for adding new simulator input. There are many igen
>files present in the source... Mips.igen, M16.igen etc...
>
>The source for 'igen' (the simulator generator used) is present at
>'src/sim/igen'. The 'igen' simulator generator takes input the
mips.igen
>file which includes other igen files and generates the simulator
source.
>
>
>The source for simulator will generate in build directory. The contents
>of this source will depend on the input 'mips.igen' file. These files
>are responsible for instruction implementation.
>
>U need new model name also to add any new instruction.
>
>Monika
>

Re: "igen based simulators doc.?"

[Andrew Cagney]

The igen/ header files describe the syntax.  As for details, as Monika 
Chaddha as suggested, the best source of info is various examples.

Andrew

Re: "Info reg doesn't work"

[Jim Blandy]

"Xinan Tang" <xinan@tidalnetworks.net> writes:
>   After gdb is started, the following captures what was happening:
> 
> _______________________________________________________
> (top-gdb) target sim
> complaining the floating point register size is wrong ...
> (top-gdb) info target
> simulator:
> (top-gdb)
> _______________________________________________________
> 
>   It seems in my gdb porting, the simulator was not found out. Where to
> start to debug this?

Well, start with remote-sim.c.

RE: "Info reg doesn't work"

[Xinan Tang]

Hi

  After gdb is started, the following captures what was happening:

_______________________________________________________
(top-gdb) target sim
complaining the floating point register size is wrong ...
(top-gdb) info target
simulator:
(top-gdb)
_______________________________________________________

  It seems in my gdb porting, the simulator was not found out. Where to
start to debug this?

Thanks

--Xinan

Re: "Info reg doesn't work"

[Jim Blandy]

"Xinan Tang" <xinan@tidalnetworks.net> writes:
>    Should I go into function _initialize_FOO_tdep() to modify the places
> where bfd_arch_arm is used? I haven't done that yet since our target is
> similar to arm.

Well, you're going to need to choose your own bfd_arch_* value, and
use that in the upstream toolchain.  Or if your processor is a variant
on the ARM, then you'll need to invent your own bfd_mach_arm_* value.
Ask on binutils@sources.redhat.com about allocating a bfd_arch or
bfd_mach value for your own use.  I haven't done this before.

RE: "Info reg doesn't work"

[Xinan Tang]

Hi Jim,

  Please help me to debug this:

  1. Assume my target is FOO, let's say it is similar to ARM.

  2. I created a FOO subdirectory in 'gdb/config/FOO' and then created a
file: 'embedd.mt' underneath, its content is:

     TDEPFILES=FOO-tdep.o ...
     TDEPLIBS=  ...
     TM_FILES=  ...
     SIM_OBS=remote-sim.o
     SIM = ../sim/arm/libsim.a

  I.e, arm-tdep.o is changed to FOO-tdep.o

  3. FOO-tdep.c is copied from arm-tdep.c in which I changed the function
name

     _initialize_arm_tdep() to _initialize_FOO_tdep()


   Should I go into function _initialize_FOO_tdep() to modify the places
where bfd_arch_arm is used? I haven't done that yet since our target is
similar to arm.

Thanks

--Xinan


-----Original Message-----
From: jimb@zenia.home [mailto:jimb@zenia.home]On Behalf Of Jim Blandy
Sent: Tuesday, June 15, 2004 2:41 PM
To: Xinan Tang
Cc: gdb@sources.redhat.com
Subject: Re: "Info reg doesn't work"



"Xinan Tang" <xinan@tidalnetworks.net> writes:
>   I am porting gdb (6.1) to a new target. After adding a new target that
is
> similar to an existing RISC 32bit architecture, I found out two problems:
>
>   1. `info register' does not work. For example, if I type in `info reg',
> the content of all registers are showing ZERO except PC no matter how many
> instructions are executed.
>
>   2. Gdb can start execution from _start but can not enter main.
>
>   Could someone please point to me which files I should take a look to fix
> this problem? Or is there any FAQ to explain how to add a new target based
> on an existing architecture.

Well, you might try looking at gdb/doc/gdbint.texi, the GDB internals
documentation.  But it sounds to me like your target is having trouble
supplying register values to GDB.

How is GDB communicating with the debuggee?  Via the remote protocol?
Via ptrace?  Something else?

Re: "Info reg doesn't work"

[Jim Blandy]

"Xinan Tang" <xinan@tidalnetworks.net> writes:
>   I am porting gdb (6.1) to a new target. After adding a new target that is
> similar to an existing RISC 32bit architecture, I found out two problems:
> 
>   1. `info register' does not work. For example, if I type in `info reg',
> the content of all registers are showing ZERO except PC no matter how many
> instructions are executed.
> 
>   2. Gdb can start execution from _start but can not enter main.
> 
>   Could someone please point to me which files I should take a look to fix
> this problem? Or is there any FAQ to explain how to add a new target based
> on an existing architecture.

Well, you might try looking at gdb/doc/gdbint.texi, the GDB internals
documentation.  But it sounds to me like your target is having trouble
supplying register values to GDB.

How is GDB communicating with the debuggee?  Via the remote protocol?
Via ptrace?  Something else?

"Info reg doesn't work"

[Xinan Tang]

Hi

  I am porting gdb (6.1) to a new target. After adding a new target that is
similar to an existing RISC 32bit architecture, I found out two problems:

  1. `info register' does not work. For example, if I type in `info reg',
the content of all registers are showing ZERO except PC no matter how many
instructions are executed.

  2. Gdb can start execution from _start but can not enter main.

  Could someone please point to me which files I should take a look to fix
this problem? Or is there any FAQ to explain how to add a new target based
on an existing architecture.

Thanks

--Xinan