On 25 March 2015 at 00:45, Antti Kantee <[email protected]> wrote:
> On 25/03/15 00:03, Justin Cormack wrote:
>>
>> As a diversion I tried a few different architectures, to get some new
>> problems.
>>
>> Arm: works other than need to work around some eabi symbol alias
>> conflicts. Should be simple to resolve.
>> Powerpc: Fails to build libc on Linux as wchar_t on linux is a long
>> while on NetBSD it is an int. Solution is probably to use NetBSD on
>> ppc32, or to build a compiler with different wchar... or find an
>> option to stop it complaining. ppc64 should be ok, will try that at
>> some point.
>
>
> Is it a printf thing or something else? There's already a -Wno-format hook
> in buildrump.sh in case there's a size_t confusion for 32bit targets.
No, it is string init:
/home/justin/frankenlibc/rumpsrc/lib/libc/gen/vis.c:109:1: error:
array of inappropriate type initialized from string constant
static const wchar_t char_shell[] = L"'`\";&<>()|{}]\\$!^~";
^
/home/justin/frankenlibc/rumpsrc/lib/libc/gen/vis.c:110:1: error:
array of inappropriate type initialized from string constant
static const wchar_t char_glob[] = L"*?[#";
^
/home/justin/frankenlibc/rumpsrc/lib/libc/gen/vis.c: In function 'do_mvis':
/home/justin/frankenlibc/rumpsrc/lib/libc/gen/vis.c:171:6: warning:
passing argument 1 of 'wcschr' from incompatible pointer type [enabled
by default]
wcschr(L"#$@[\\]^`{|}~", c) != NULL)) {
^
In file included from /home/justin/frankenlibc/rumpsrc/lib/libc/gen/vis.c:75:0:
/home/justin/frankenlibc/rumpobj/tooldir/dest/usr/include/wchar.h:108:10:
note: expected 'const wchar_t *' but argument is of type 'const long
int *'
wchar_t *wcschr(const wchar_t *, wchar_t);
^
I havent found a way to disable yet. Trying clang to see if it
suggests an error to ignore.
>> mips: runs fine apart from my fiber switching code is broken, will fix it.
>
>
> See mips run for not very long if it can't context switch ;)
Indeed. gdb is not very helpful, will require more coffee.
>
> Hijacking this thread a bit, some time ago there was discussion about how
> you should tell the target architecture to build-rr.sh in rumprun. Due to
> last week's toolchain wrapper work, I think the answer is now manifest.
> Target architecture selection can work exactly the same way as it works for
> buildrump.sh: inferred from the compiler.
>
> So if you do "CC=i386-whatever-gcc ./build-rr.sh xen", you get a i386
> version of rumprun for xen, and if you do "CC=arm-whatever-cc ./build-rr.sh
> baremetal" you get an error, since there's no such thing as a generic arm
> board. So we probably need some switch like -b(oard). But that becomes
> relevant only when support for the first ARM board hits /baremental.
Yes, frankenlibc works like that too. I will probably move the -F
flags parsing to subr.sh as at the moment I have it duplicated, as if
you do ./buildc -F ACLFLAGS=-m32 I need to extract that and use it to
compile the parts that are not compiled with rumpmake
> Also, summarizing the proposed terminology:
>
> architecture = CPU ISA
> platform = the layer above architecture (baremetal, frankenlibc, xen)
> board = specific hardware configuration (probably valid only for
> /baremetal?)
>
Frankenlibc is not a platform, it has platforms (inconsistently called
OS in the Makefiles but platform in the code), these are currently
linux, freebsd, netbsd, and are autodetected from the compiler, but
that wont be the case eg with most of the microkernels which use
generic compilers so you will need to specify.
Existing baremetal platform should probably be called "pc" or similar.
Justin
