summaryrefslogtreecommitdiffstats
path: root/c/src (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>. The following emailJoel Sherrill1999-02-241-8/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | is long but I hate to lose the information so I am including it here. > I am still fixing and recompiling but this is the issue that was not the > result of another patch. This is a fundamental build issue that I value > your opinion on. This is difficult issue (I.e. I have no destinct solution for it) Background: (gnu-) make's implicit rules apply CFLAGS, CPPFLAGS, CXXFLAGS, ASFLAGS and LDFLAGS (cf. make.info/Implicit Rules/Catalogue of Rules), only. In brief: CPPFLAGS .. passed to the c-preprocessor CFLAGS ... passed to the c-compiler CXXFLAGS ... equivalent to CFLAGS but passed to the c++ compiler (Attention: CFLAGS is not passed to the c++ compiler) ASFLAGS .. equivalent to CFLAGS, but passed to the assembler LDFLAGS .. equivalent to CFLAGS, but passed to the linker A bit oversimplifying, these make rules are as follows .c.o: $(CC) $(CPPFLAGS) $(CFLAGS) -c .cc.o: $(CXX) $(CPPFLAGS) $(CXXFLAGS) -c .S.s: $(CPP) $(CPPFLAGS) .s.o: $(AS) $(ASFLAGS) My reading of the documentation (make.info) is that {AS|AR|CC|CXX|CPP}FLAGS are ment to be passed to the related tools directly, however examinating the rule set of gmake (gmake -p -f /dev/null") shows that many rules use $(CC) instead of the related tools (eg. linker rules) etc. I.e. these flags should not rely on being passed through cpp or gcc. With gcc being the common frontend for all of these tools of a gnu-toolchain the situation becomes difficult (Which option is passed to whom and which tool really uses it?), because these variable can also contain the toolchain's frontend (eg. AS=gcc, LD=gcc, CPP=gcc -E). For some commonly used options the situation is quite clear: * -g -> CFLAGS * -OX -> CFLAGS * -D -> CPPFLAGS * -A -> CPPFLAGS But where to add -m, -B, -specs, -qrtems_XXX ? * -B, -specs, -qrtems_XXX are gcc-frontend options * -m is a combinations of flags to go to different destinations, in many (all?) cases, the following is valid -m is expanded by gcc into a set of -D and -A options -m is interpreted by cc1 as a machine flag to generate a specific instruction set. -m is interpreted by gcc as an implicit linker search path for multilibs to set up calls to LD. >From my point of view this indicates we can either destingush between these different usages (= separately add -m to CFLAGS, LDFLAGS etc) or to add it to CPPFLAGS and use gcc (the frontend) instead of calling each tool directly (less error prone) -- I vote for CPPFLAGS, but I am not sure. ----------------- Now, where to add CPU_CFLAGS? AFAIS, in probably all cases CPU_CFLAGS contain -D -A, and -m options, only. * -D and -A are supposed to go to CPPFLAGS * -mXXX options can have multiple meanings (It can be gcc, collect2/ld and cc1/cc1plus option simultaneously) Here, I made a mistake - I destinguished between CPU_DEFINES to be added to CPPFLAGS and CPU_CFLAGS to be added to CFLAGS and CXXFLAGS (cf. gcc-target-default.cfg), generally assuming CPU_CFLAGS are CFLAGS. This breaks preprocessing *.S into *.i files because CPU_CFLAGS flags were not added to CPPFLAGS. Hence *all* *.S were compiled without taking -mXX-flags into account. The i960/cvme BSP was the only one which explicitly checked for a specific -m flag (-mca) and refused to compile without it -- all other CPUs/BSPs silently swallowed this. IMO, we can either 1) add CPU_CFLAGS and CPU_DEFINES to CPPFLAGS, thus silently convert CPU_CFLAGS's meaning into CPU_DEFINES (Alternative solution: rename CPU_CFLAGS to CPU_DEFINES and merge CPU_FLAGS with CPU_DEFINES). or 2) destinguish between CPU_DEFINES and CPU_CFLAGS. In this case we would need to check the contents of each CPU_CFLAGS in custom/*.cfg and move the some parts of the contents to CPU_DEFINES and keep other parts in CPU_CFLAGS (CFLAGS must contain options for the c/c++-compiler only!). Though Solution 2) is the clearer one, I implemented 1) which is the simplier one (the patch below). ATTENTION: This patch is small in size, but affects almost everything. ------------ Additional complications araise with linking: Some BSPs call LD and AS directly (esp. gcc-2.7 make-exe rules). If LD=gcc then LDFLAGS are supposed to be gcc-options, but if LD=ld then LDFLAGS is supposed to contain ld-options. An analog thought is valid for AS, but luckily enough ASFLAGS is not used of inside the whole source tree. Most RTEMS' custom/*.cfg use $(CC) $(CFLAGS) to link with gcc-2.8 make-exe rules. With the patch below (CPU_CFLAGS added to CPPFLAGS) this means CPU_CFLAGS will not be passed to the linker, which is incorrect for multilibbed CPU's. gmake's default rule set contains a variety of rules for linking, all ending up in calling $(CC) $(LDFLAGS) for linking at their very end. IMO, this means we should use something like LINK.o = $(CC) $(LDFLAGS) in gcc-target-default.cfg + modify all gcc-2.8 make-exe rules to use $(LINK.o) ....... + setup LDFLAGS according to the requirements of the above. I.e. we should use $(CC) for linking instead of calling the linker (LD) directly and set LDFLAGS = $(CPPFLAGS) $(CFLAGS) or similar.
* Removed dependency on bsp.h.Joel Sherrill1999-02-241-1/+3
|
* Corrected name of file.Joel Sherrill1999-02-241-1/+1
|
* Changed to include FPSP in library.Joel Sherrill1999-02-241-0/+2
|
* Changed from $(INSTALL) to $(INSTALL_CHANGE).Joel Sherrill1999-02-242-3/+3
|
* Corrected Makefile.in to account for placement of include files.Joel Sherrill1999-02-244-4/+4
|
* Corrected name of constant so this would compile.Joel Sherrill1999-02-241-1/+1
|
* Accidentally moved.Joel Sherrill1999-02-194-2101/+0
|
* Moved back up in tree.Joel Sherrill1999-02-194-0/+2101
|
* Accidentally moved erc32.hJoel Sherrill1999-02-191-521/+0
|
* Moved erc32.h back up in tree.Joel Sherrill1999-02-192-0/+1042
|
* Moved asm.h back up in tree.Joel Sherrill1999-02-198-0/+970
|
* Accidentally moved asm.hJoel Sherrill1999-02-198-1143/+0
|
* Moved to proper rtems/scoreJoel Sherrill1999-02-1923-738/+423
|
* Enhanced to support -qrtems_debug.Joel Sherrill1999-02-191-3/+9
|
* BSP for Vista Score603e added.Joel Sherrill1999-02-1944-0/+6467
|
* Patch from Ian Lance Taylor <ian@airs.com>:Joel Sherrill1999-02-181-6/+6
| | | | | | | | | Here is a patch which slightly improves the i386 interrupt handling macros. These macros were written to use both input and output parameters, which is not necessary. This patch changes them to use only an input or output parameter, as appropriate. It also changes the constraints to permit the interrupt level to be loaded directly in and out of memory, rather than always requiring a register.
* Renamed network to wd8003.Joel Sherrill1999-02-184-4/+4
|
* Patch from Emmanuel Raguet <raguet@crf.canon.fr>. Missed adding this fileJoel Sherrill1999-02-181-0/+540
| | | | earlier to CVS.
* Added INSTALL rule to Makefile.Joel Sherrill1999-02-189-3/+19
|
* Patch from Emmanuel RAGUET <raguet@crf.canon.fr> to add filesJoel Sherrill1999-02-185-8/+942
| | | | | | that were accidentally not committed earlier. The DECNet driver is being added as its own directory to avoid forcing the driver to have to pull in the complete set of network drivers.
* Added comments.Joel Sherrill1999-02-181-0/+20
|
* Added NE2000 Driver from Ian Lance Taylor <ian@airs.com>. Comments:Joel Sherrill1999-02-184-2/+998
| | | | | | | | | | | | | | | | | | | | | | Both the ne2000 and the wd80x3 are based on the National Semiconductor 8390 chip, so there is a fair amount of overlap between the two drivers. It would be possible in principle to combine some code into a separate set of subroutines called by both. In fact, the drivers in both OpenBSD and Linux work this way. I didn't bother, because for the relatively simple drivers used by RTEMS, the overlap is not especially large, and any reasonable use of subroutines would lead to slightly less efficient code. This ne2000 driver uses two transmit buffers. While one packet is being transmitted over the Ethernet, RTEMS will upload another. Since uploading a packet to the ne2000 is rather slow, I don't think there is any point to having more than two transmit buffers. However, the code does make it possible, by changing NE_TX_BUFS, although that would of course reduce the number of receive buffers. I suspect that the wd80x3 driver would benefit slightly from copying the multiple transmit buffer code. However, I have no way to test that.
* Fixed top of file.Joel Sherrill1999-02-181-1/+3
|
* MVME167 BSP submitted by Charles Gauthier <Charles.Gauthier@iit.nrc.ca>.Joel Sherrill1999-02-1824-0/+4003
|
* Missed this file in the merge.Joel Sherrill1999-02-181-0/+412
|
* Part of the automake VI patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>:Joel Sherrill1999-02-18639-329/+1605
| | | | | | | | | | | | | | | | > 5) rtems-rc-19990202-1.diff/reorg-install.sh > > reorg-install.sh fixes a Makefile variable name clash of RTEMS > configuration files and automake/autoconf standards. > Until now, RTEMS used $(INSTALL) for install-if-change. Automake and > autoconf use $(INSTALL) for a bsd-compatible install. As > install-if-change and bsd-install are not compatible, I renamed all > references to install-if-changed to $(INSTALL_CHANGED) and used > $(INSTALL) for bsd-install (==automake/autoconf standard). When > automake will be introduced install-if-change will probably be replaced > by $(INSTALL) and therefore will slowly vanish. For the moment, this > patch fixes a very nasty problem which prevents adding any automake file > until now (There are still more).
* Part of the automake VI patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>:Joel Sherrill1999-02-1886-0/+17420
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > 4) rtems-rc-19990202-0.diff /reorg-score-cpu.sh > > reorg-score-cpu.sh reorganizes the cpu/<cpu>/* subdirectories in a > similar manner than previous reorg scripts did. rtems-rc-19990202-0.diff > contains the diffs after reorg-score-cpu.sh has been run on a > rtems-19981215 snapshot + my patches up to rtems-rc-19990131-2.diff. > > This patch is rather nasty and may break something. However, I've tested > it for about 10 different target/bsp pairs and believe to have shaken > out most bugs. I wonder about the following .h files that were not moved: a29k/asm.h a29k/cpu_asm.h i386/asm.h i960/asm.h m68k/asm.h m68k/m68302.h m68k/m68360.h m68k/qsm.h m68k/sim.h mips64orion/asm.h mips64orion/cpu_asm.h mips64orion/mips64orion.h no_cpu/asm.h no_cpu/cpu_asm.h powerpc/asm.h powerpc/mpc860.h sh/asm.h sparc/asm.h sparc/erc32.h
* Another part of automake VI patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>Joel Sherrill1999-02-181-0/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > 4) rtems-rc-19990202-0.diff /reorg-score-cpu.sh > > reorg-score-cpu.sh reorganizes the cpu/<cpu>/* subdirectories in a > similar manner than previous reorg scripts did. rtems-rc-19990202-0.diff > contains the diffs after reorg-score-cpu.sh has been run on a > rtems-19981215 snapshot + my patches up to rtems-rc-19990131-2.diff. > > This patch is rather nasty and may break something. However, I've tested > it for about 10 different target/bsp pairs and believe to have shaken > out most bugs. I wonder about the following .h files that were not moved: a29k/asm.h a29k/cpu_asm.h i386/asm.h i960/asm.h m68k/asm.h m68k/m68302.h m68k/m68360.h m68k/qsm.h m68k/sim.h mips64orion/asm.h mips64orion/cpu_asm.h mips64orion/mips64orion.h no_cpu/asm.h no_cpu/cpu_asm.h powerpc/asm.h powerpc/mpc860.h sh/asm.h sparc/asm.h sparc/erc32.h
* Yet another part of automake VI from Ralf Corsepius <corsepiu@faw.uni-ulm.de>:Joel Sherrill1999-02-1854-15615/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > 4) rtems-rc-19990202-0.diff /reorg-score-cpu.sh > > reorg-score-cpu.sh reorganizes the cpu/<cpu>/* subdirectories in a > similar manner than previous reorg scripts did. rtems-rc-19990202-0.diff > contains the diffs after reorg-score-cpu.sh has been run on a > rtems-19981215 snapshot + my patches up to rtems-rc-19990131-2.diff. > > This patch is rather nasty and may break something. However, I've tested > it for about 10 different target/bsp pairs and believe to have shaken > out most bugs. I wonder about the following .h files that were not moved: a29k/asm.h a29k/cpu_asm.h i386/asm.h i960/asm.h m68k/asm.h m68k/m68302.h m68k/m68360.h m68k/qsm.h m68k/sim.h mips64orion/asm.h mips64orion/cpu_asm.h mips64orion/mips64orion.h no_cpu/asm.h no_cpu/cpu_asm.h powerpc/asm.h powerpc/mpc860.h sh/asm.h sparc/asm.h sparc/erc32.h
* Part of the automake VI patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>:Joel Sherrill1999-02-1811-73/+10
| | | | | | | | | | | | | | | | | | > 3) rtems-rc-19990131-2.diff > > This patch removes generating bsp_specs from leaf.cfg and generates > bsp_specs from inside of c/Makefile instead. > > The motivation behind this patch is to avoid "polluting" Makefiles by > unneccessary rules from included Makefile-fragments (*.cfg-files) and > try to handle files by explicit rules in Makefiles instead (FYI: > automake-1.4 physically includes Makefile fragments at the time > automake is run, not at the time make is run as RTEMS Makefile.ins do > now) > > Nevertheless, this patch is rather uncritical, almost cosmetical - If > you don't like it, then dump it ;-, however I doubt that subsequent > patches will apply then ;-.
* Added rejected patch from automake VI from Ralf Corsepius.Joel Sherrill1999-02-181-6/+9
|
* Part of automake VI patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>:Joel Sherrill1999-02-182-49/+27
| | | | | | | | | | | | | | > 2) rtems-rc-19990131-1.diff > > Rework of compilers/*.cfg files (esp. gcc-target-default.cfg) to adapt > the flags/makefile variables to automake and make standards (cf. > make.info - implicit rules/variables). > > This patch is rather risky and may probably break things, but is an > essential step towards automake. > > FWIW: It also reverts the i386-ASMFLAGS/ASFLAGS-patch, which was wrong, > as I had to experience ;-.
* Part of automake VI Patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>.Joel Sherrill1999-02-181-0/+3
| | | | | | | > Adds variables to the custom/*cfg files to specify the location of > tools. The purpose is to remove hard-coded paths from the Makefiles. > > In later steps this eases moving the tools to other locations.
* Corrected.Joel Sherrill1999-02-181-36/+0
|
* Readded.Joel Sherrill1999-02-181-0/+14
|
* Should have been removed earlier.Joel Sherrill1999-02-1843-5878/+0
|
* Patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>:Joel Sherrill1999-02-1812-69/+60
| | | | | | | | | | | | | This patch removes generation of targopts.h from leaf.cfg and generates it in location at score/include/rtems/score instead. To achieve this: * all rules in other Makefile.ins which have accessed targopts.h have been removed. * c/Makefile.in has been modified to generate the directories before doing anything else. I.e. to ensure the directories exist before any preinstall rule fires (This part is a bit kludgy, but it seems to work. Please check if the interaction with libhwapi still works).
* ./clock/Makefile.in,vJoel Sherrill1999-02-1868-0/+13249
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ./clock/clock.c,v ./console/Makefile.in,v ./console/config.c,v ./console/console.c,v ./console/console.h,v ./console/debugio.c,v ./console/i8042.c,v ./console/i8042_p.h,v ./console/i8042vga.c,v ./console/i8042vga.h,v ./console/ns16550.c,v ./console/ns16550.h,v ./console/ns16550_p.h,v ./console/ns16550cfg.c,v ./console/ns16550cfg.h,v ./console/vga.c,v ./console/vga_p.h,v ./console/z85c30.c,v ./console/z85c30.h,v ./console/z85c30_p.h,v ./console/z85c30cfg.c,v ./console/z85c30cfg.h,v ./include/Makefile.in,v ./include/bsp.h,v ./include/chain.h,v ./include/coverhd.h,v ./include/extisrdrv.h,v ./include/nvram.h,v ./include/pci.h,v ./include/tod.h,v ./network/Makefile.in,v ./network/amd79c970.c,v ./network/amd79c970.h,v ./nvram/Makefile.in,v ./nvram/ds1385.h,v ./nvram/mk48t18.h,v ./nvram/nvram.c,v ./nvram/prepnvr.h,v ./nvram/stk11c68.h,v ./pci/Makefile.in,v ./pci/pci.c,v ./start/Makefile.in,v ./start/start.s,v ./startup/Makefile.in,v ./startup/bspclean.c,v ./startup/bspstart.c,v ./startup/bsptrap.s,v ./startup/device-tree,v ./startup/genpvec.c,v ./startup/linkcmds,v ./startup/rtems-ctor.cc,v ./startup/sbrk.c,v ./startup/setvec.c,v ./startup/spurious.c,v ./startup/swap.c,v ./timer/Makefile.in,v ./timer/timer.c,v ./tod/Makefile.in,v ./tod/cmos.h,v ./tod/tod.c,v ./universe/Makefile.in,v ./universe/universe.c,v ./vectors/Makefile.in,v ./vectors/README,v ./vectors/align_h.s,v ./vectors/vectors.s,v ./wrapup/Makefile.in,v ./Makefile.in,v ./README,v ./STATUS,v ./bsp_specs,v
* ./clock/Makefile.in,vJoel Sherrill1999-02-181-0/+114
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ./clock/clock.c,v ./console/Makefile.in,v ./console/config.c,v ./console/console.c,v ./console/console.h,v ./console/debugio.c,v ./console/i8042.c,v ./console/i8042_p.h,v ./console/i8042vga.c,v./console/i8042vga.h,v ./console/ns16550.c,v ./console/ns16550.h,v ./console/ns16550_p.h,v ./console/ns16550cfg.c,v ./console/ns16550cfg.h,v ./console/vga.c,v ./console/vga_p.h,v ./console/z85c30.c,v ./console/z85c30.h,v ./console/z85c30_p.h,v ./console/z85c30cfg.c,v ./console/z85c30cfg.h,v ./include/Makefile.in,v ./include/bsp.h,v ./include/chain.h,v ./include/coverhd.h,v ./include/extisrdrv.h,v ./include/nvram.h,v ./include/pci.h,v ./include/tod.h,v ./network/Makefile.in,v ./network/amd79c970.c,v ./network/amd79c970.h,v ./nvram/Makefile.in,v ./nvram/ds1385.h,v ./nvram/mk48t18.h,v ./nvram/nvram.c,v ./nvram/prepnvr.h,v ./nvram/stk11c68.h,v ./pci/Makefile.in,v ./pci/pci.c,v ./start/Makefile.in,v ./start/start.s,v ./startup/Makefile.in,v ./startup/bspclean.c,v ./startup/bspstart.c,v ./startup/bsptrap.s,v ./startup/device-tree,v ./startup/genpvec.c,v ./startup/linkcmds,v ./startup/rtems-ctor.cc,v ./startup/sbrk.c,v ./startup/setvec.c,v ./startup/spurious.c,v ./startup/swap.c,v ./timer/Makefile.in,v ./timer/timer.c,v ./tod/Makefile.in,v ./tod/cmos.h,v ./tod/tod.c,v ./universe/Makefile.in,v ./universe/universe.c,v ./vectors/Makefile.in,v ./vectors/README,v ./vectors/align_h.s,v ./vectors/vectors.s,v ./wrapup/Makefile.in,v ./Makefile.in,v ./README,v ./STATUS,v ./bsp_specs,v
* Should have been removed from cvs early.Joel Sherrill1999-02-1831-5253/+0
|
* Patch from Emmanuel Raguet <raguet@crf.canon.fr>:Joel Sherrill1999-02-186-3/+192
| | | | | | | You will find enclosed a patch which contains, for Intel PC386 target : - an Ethernet driver for DEC21140 device based boards. - a simple cache management with paging mechanism.
* GLobal reentrancy structure is now dynamically initialized.Joel Sherrill1999-02-182-2/+4
|
* Added CVS Id string.Joel Sherrill1999-02-181-0/+4
|
* Added or corrected CVS Id strings.Joel Sherrill1999-02-187-5/+11
|
* MPC860 support submitted by Jay Monkman <jmonkman@frasca.com>.Joel Sherrill1999-02-184-2/+256
|
* Jay Monkman <jmonkman@frasca.com> submitted the eth_comm BSP for a PPC860Joel Sherrill1999-02-1740-0/+8905
| | | | based board.
* Patch from Eric Valette <valette@crf.canon.fr> to undo the patchJoel Sherrill1999-02-152-4/+0
| | | | that added ifdef on the pc386.
* Patch from Eric Valette <valette@crf.canon.fr> to correct _exitJoel Sherrill1999-02-151-2/+1
| | | | undefined problem.
* changed version to 19990210Joel Sherrill1999-02-101-1/+1
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-03 08:37:39 +0000