1. Rtems contains some perl scripts that use hard-coded paths to
/usr/bin/perl or /usr/local/bin/perl I have already fixed these
problems by adding some checks to configure.in. While doing this,
I also cleaned up some more autoconf related problems for generating
shell scripts. This patch might seem a bit scary to you, but I am
quite confident it won't break something (I've been testing it for
almost a week now, however it might introduce typos for a limited
number configurations I don't have access to - But it shouldn't be
a problem for you to test them :-).
I expect to get this finished tonight, hence you will very likely
have the patch when you get up tomorrow.
Changes:
* Check for PERL and disable all PERL scripts if perl wasn't found.
* Generate all KSHELL-scripts with autoconf instead of make-script
* Automatic dependency handling for autoconf generated KSHELL or PERL
scripts (make/rtems.cfg)
Notes:
* this patch contains new files and deletes some other files.
* The patch is relative to rtems-4.0.0-beta4 with my previous
rtems-rc-981014-1.diff patch applied.
Testing:
I tested it with sh-rtems and posix under linux. Now all targets
which are touched by this patch and which are not used while building
for sh-rtems and posix still need to be tested. AFAIS, only the
sparc/erc32 BSP should be affected by this criterion. And if you
like to, you should also consider testing it on a Cygwin32 and a
Solaris host for one arbitrary BSP.
2. "make profile" doesn't work. It aborts when building host-tools
for embedded targets. I didn't yet have enough time to fix this
problem. AFAIS this problem is related to handling of
LDFLAGS_PROFILE[|_V] in gcc.cfg.in. For host applications, we use
gcc for linking host applications, too. With profiling enabled
CFLAGS_PROFILE_V contains -pg and is used to compile, but
LDFLAGS_PROFILE_V is empty, hence -pg will not be passed to the
linker causing gcc to fail to link, because it can't resolve some
symbols introduced by compiling with -pg.
I am not sure if I can provide a patch for this - Ether it is trivial
to fix or requires basic work on host configuration ;-
Fixing this one was trivial - But hard to trace.
LDFLAGS_PROFILE_V needs to contain the same flags as CFLAGS_PROFILE_V,
if gcc is used for linking (What else should have been expected ?,
:-). The same problem was present for *_DEBUG_V, but apparently wasn't
noticed by anybody, because things didn't break, but were silently
ignored.
I fixed these problems by setting these flags in configure.in whenever
gcc is reported to be the host-compiler. For non-gcc host compilers
"make debug" and "make profile" now becomes the same as an ordinary
"make". This is a hack and addressing this problen could be more
sophisticated, but I don't think it gives much sense to support
compile variants for any host program (Who will ever try to
profile/debug host tools?). Therefore I don't think it's useful
to invest more effort into this problem.
moves pieces of the pc386 bsp up to a shared level for all i386 BSPs
and modifies the i386ex BSP to use those shared pieces. Serial remote
debugging is included for both targets. Erik's notes:
There are several workarounds in it:
1) #define NEXT_GAS is hardcoded in pc386/start/start.s
2) #define NEXT_GAS is hardcoded in i386ex/start/start.s
3) #define NEW_GAS is hardcoded in pc386/start16.s
4) #undef __assert and redeclare _assert hardcoded in console.c for
both pc386 and i386ex due to my egcs1.1b ~ newlib problem. Should have
modified t-rtems.cfg ( no time )
I've tested pc386 with both video and serial consoles and GDB remote.
All work fine, except that GDB acts weird. ( re: other posting)
I hope this will work for you. It took quite some time to locate the
autoconf error. The remainder was just grunt work.
Unfortunately, I think I've unwound the removal of the IBMPCInitVideo
stuff. Sorry. I REALLY can't spend more time... I've been at this
conversion to 4.0 locally and updating the release since Sept. 8th, and
have yet to compile my network driver.... This is as much as I can do
right now.
I look forward to the next patch to really test i368ex. I did make sure
that the sample tests worked for pc386.
As mentioned in other mails before, there is are minor inconsistencies in the
posix custom/*cfg files.
Linux-posix.cfg sets RTEMS_BSP=posix
FreeBSD-posix.cfg sets RTEMS_BSP=posix
Solaris-posix.cfg first sets RTEMS_BSP=posix, later it sets
RTEMS_BSP=solaris2
1. Setting RTEMS_BSP=posix is redunant to settings in default.cfg
2. The solaris variant of setting RTEMS_BSP is merely non-functional.
The patch attached to this mail should clean up this issue.
The patch was tested by building the posix bsp under
i686-pc-linux-glibc1/glibc2 and Solaris2.6 (I did not run any
rtems program, however) The HPUX9 and FreeBSD configuration files
were adapted in analogy to the solaris and linux configurations.
The reentrant versions of the malloc functions in
c/src/lib/libc/malloc.c
do not match the definitions in newlib. These will be used if you use
newlib routines such as fdopen. I believe this patch to malloc.c is
needed to provide the correct versions.
- c/src/exec/score/cpu/powerpc/ppc.h: some small changes
(added ppc403 characteristics like a exception vector prefix
register, some special register definitions). I am quite sure, they
are compatible with the existing sources, although I did not check
- c/src/exec/score/cpu/powerpc/cpu.c: There is one severe
limitation in the exception entries: Due to the current code
arrangement, the "branch absolute" to the ISR handler may only
jump to the first 128MByte or the last 128MByte of the 4GByte
address range. When the ppc403 is running out of ROM, the ROM
functions are located in the last 128MByte (0xFFF00000 and up).
These addresses were not handled correctly (sign reduced) in
"install_raw_handler". The change I added should work on existing
ppc BSPs aswell...
