This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
RE: [PATCH] Commandline Support for the H8300 Simulator.
- From: "D.Venkatasubramanian, Noida" <dvenkat at noida dot hcltech dot com>
- To: "J. Johnston" <jjohnstn at redhat dot com>, Nick Clifton <nickc at redhat dot com>
- Cc: newlib at sources dot redhat dot com
- Date: Wed, 26 Feb 2003 10:14:52 +0530
- Subject: RE: [PATCH] Commandline Support for the H8300 Simulator.
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.
>-- Jeff J.
>
Thanks in Anticipation,
Best Regards,
Venky