[PATCH] Commandline Support for the H8300 Simulator.

[J. Johnston]

D.Venkatasubramanian, Noida wrote:
> Hi,
> 
> 
>>Venky,
>>
>>  You are adding a flag to configure.host that will always be
>>on, yet you state that this is only for the simulator.  I don't
>>see the point of the flag if you are not going to optionally turn
>>it on or off.  What is your intention?  The current code in the
>>sys directory is sim-dependent at the moment.  I would like to
>>see in the future that this code be migrated to libgloss and
>>a special sim package built.
>>
> 
> 
> Well, I had raised this question earlier:
> http://sources.redhat.com/ml/binutils/2003-01/msg00344.html
> 
> My intention is to be able to support commandline 
> arguments only on the simulator as a real target 
> may not be capable to do so. So, when I had 
> suggested (quite naively) a additional compiler 
> option like -msim to specify compilation for a 
> simulator, Nick had pointed out that would be a 
> bad idea. And I do agree to that. Nick had 
> suggested this mechanism, this is similar to the 
> ARM implementation (I may be wrong, though). 
> 
> 
>>>>In the context, I was actually trying to include commandline support
>>>>to the simulator and so would have to setup the stack with the
>>>>commandline arguments in crt0.S. I didn't think it would be a good
>>>>idea to add the code to the default implementation, by adding the
>>>>target, we could write any simulator specific code inside a #ifdef
>>>>__SIMULATOR__ kind of structure, similar to the ARM implementation.
>>>
>>>Are you saying that the default target execution environment for H8300
>>>binaries does not have any way of obtaining its command line ?  So you
>>>want to invent one that will work with the simulator ?  If so, then I
>>>can understand your desire to have a "-msim" switch, but I still think
>>>that it is a bad idea.  Instead I would suggest that you do something
>>>similar to the mechanism used in newlib for the ARM.
>>>
>>>In the file newlib/configure.host, for the h8300 entry, add an new
>>>define, eg -DSIMULATOR_ARGV_SUPPORT and then test for this in crt0.S.
>>>You still end up with a customised-for-the-simulator crt0.o file, but
>>>these do tend to be execution environment specific, and normally a
>>>user would use a spec file to select the correct crt0.o for their
>>>execution environment.
>>>
>>>Cheers
>>>       Nick
>>
> 
> By the way, is there some other way to do it, 
> that is generate a jsr 0xcc instruction in the 
> startup code, get the real target to ignore it, 
> but the simulator to simulate it. I want to set 
> some flag that can be optionally turned on.
> 

I was not privy to your original conversation with Nick.

Let me start with what the right way to do all of this is.  The code in
libc/sys/h8300hms does not belong in newlib.  It should be in libgloss.
That way, a user can use newlib and link in multiple board-support packages
(e.g. a simulator package vs an evaluation board package).  In libgloss
you could share files or use separate ones so as to build a simulator library
and whatever board configurations you wanted to support.  Typically, you
would have a sim-crt0.S, a sim.ld, and in the Makefile, you would build a
special libsim.a.  The sim.ld would specify the sim-crt0.S and libsim for
linking.  The user would only have to specify -Tsim.ld on the compile/link.
I have paved the way for this migration by adding the new configuration option:
--disable-newlib-supplied-syscalls

Now, I am not going to ask you to make this migration now.  It is meant
to be gradual over time.

I can live with a define as long as it is not the default.  That means that
it must be commented out in configure.host and a comment added that says
to uncomment the following line if you want to enable the particular feature.
Note that the define name should start with __.  I recommend considering renaming
it __SIMULATOR__ and noting in the comment that this define enables
simulator-only features such as argv support.  This allows future simulator
enhancements without having to add a flag for each individual feature.

-- Jeff J.