Customizing remote-sim.c on a multi-arch target

Customizing remote-sim.c on a multi-arch target

[Jon Beniston]

Hi,

I'm trying to customize remote-sim.c on a multi-arch target, what I'd
look to do is be able to define TARGET_REDEFINE_DEFAULT_OPS so I can
install hooks to support h/w watchpoints and async execution in my
simulator. Where should this macro be defined? Is this not compatible
with the multi-arch approach (I notice config/cpu/tx-cpu.h is not
included for multi-arch builds).

Cheers,
Jon

Re: Customizing remote-sim.c on a multi-arch target

[Andrew Cagney]

> Hi,
> 
> I'm trying to customize remote-sim.c on a multi-arch target, what I'd
> look to do is be able to define TARGET_REDEFINE_DEFAULT_OPS so I can
> install hooks to support h/w watchpoints and async execution in my
> simulator. Where should this macro be defined?

Rather than define these macros, what about implementing a new target 
(inferior) vector that meets your needs?  This is what

> Is this not compatible
> with the multi-arch approach (I notice config/cpu/tx-cpu.h is not
> included for multi-arch builds).

The tm-cpu.h files are obsolete.  Instead things are implemented using 
an architecture (gdbarch) and target (inferior) vector.

You may also be interested in this:
http://sources.redhat.com/gdb/papers/multi-arch/real-multi-arch/

Andrew

RE: Customizing remote-sim.c on a multi-arch target

[Jon Beniston]

> > 
> > The target vectors are already there (i.e. 
> to_insert_watchpoint). It's 
> > a question of how/when do I set them to point to the right thing.
> > 
> > I'm guessing that I need to add some architecture vectors (i.e. 
> > set_gdbarch_sim_*), and somehow get the target vector code to pick 
> > these up, but that doesn't seem quite right.
> 
> Possibly, there are choices here and both are correct:
> 
> - gdb
> Using knowledge of the architectures debug registers.  A 
> combination of 
> target and architecture.
> 
> - the inferior
> Using local knowledge.
> 
> The latter would mean additions to include/gdb/remote-sim.h

This is what I was planning on doing, however, if I do add the 3 or 4
required functions, it would mean that I would need to add these
functions to all of the simulators. Is that the best way to go about it,
or does it make sense to add a per architecture hook that only installs
them if available?

Cheers,
JonB