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] |
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] |