This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Commandline Support for the H8300 Simulator.


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]