This is the mail archive of the crossgcc@sourceware.cygnus.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more infromation.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
William Gatliff writes: > What I meant was that, according to Jeff, gcc brute-force calls _main() from main() because: > > * it needs to be called somewhere, and > * on most desktop hosts (i.e. Linux), we can't assume that it gets called anywhere else. > > If someone ports gcc to a new architecture, they should (for now) still leave the > _main() call intact, even though it's kinda annoying, because it's only a matter of time > before Linux will run on that target, at which point the _main() call *has* to be there. > > In other words, for as long as gcc has to generate a call to _main() itself, I want it to do > it consistently across all supported platforms, because it saves the gcc maintainers some > work in the long run. For that, a small wart on my code is a fair trade. gcc generates calls to __main for only a subset of the supported targets. For example you won't find calls to __main in the m32r-elf port. :-) Neither does the i386-linux port generate calls to __main. I could go back and check, but I'm guessing that the i386-linuxaout port *does* generate calls to __main, but i386-linuxaout is deprecated if not ancient history. > There is a better way out there, I'm sure, and changing things would definitely remove more > of gcc "black box" behavior in this department. For now, however, I'm content because, > despite all the warts, it still works pretty well. Sure. And cleaning it up will be a lot of work. GCC could, however, decide and document a direction if not a solution and have ports slowly fixed over time and require new ports to not do deprecated things. > > These issues are orthogonal to anything embedded-linux related. > > Now that I understand your position a bit better, I agree. However, how many projects depend > on things working the way they are? If in a future release of gcc we tell every other > project that they must add explicit commands to link runtime library files et al, for > example, we'll break a lot of shit, right? That's why gcc will probably always need to make > special concessions for desktop users... Certainly we can't break things for desktop and embedded users. ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |