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

["D.Venkatasubramanian, Noida" <dvenkat at noida dot hcltech dot com>]

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