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.


Hi,

Done as you had suggested. Sorry for the late reply,
I was just making and testing some other changes in
the GDB parts of the patch.

I am submitting only the newlib part here.

GDB part can be viewed at :
http://sources.redhat.com/ml/gdb-patches/2003-03/msg00357.html

Is it OK?

Thanks and Regards,

Venky

>-----Original Message-----
>From: J. Johnston [mailto:jjohnstn at redhat dot com]
>Sent: Friday, February 28, 2003 2:57 AM
>To: D.Venkatasubramanian, Noida
>Cc: Nick Clifton; newlib at sources dot redhat dot com
>Subject: 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.
>
>

Attachment: configure_host_patch.txt
Description: Text document

Attachment: crt0_S_patch.txt
Description: Text document

Attachment: newlib_ChangeLog.txt
Description: Text document


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