[PATCH] Commandline Support for the H8300 Simulator.
Thu Feb 27 21:26:00 GMT 2003
D.Venkatasubramanian, Noida wrote:
>> 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:
> 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
> 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:
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.
More information about the Newlib