***terpri_ is now known as terpri
<janneke>dannym: there's also some bad news... <janneke>$ ./arm-unknown-linux-gnueabihf-tcc --help <janneke>qemu: uncaught target signal 11 (Segmentation fault) - core dumped <janneke>tcc.S:83120 :Recieved invalid other; strh__%r2,(%r1) <janneke>mescc: failed: M1 --LittleEndian --architecture armv7l -f mes-source/lib/arm-mes/arm.M1 -f tcc.S -o tcc.o <dannym>janneke: It should store a half-word <dannym>janneke: Ah, yeah, too few underlines <janneke>dannym: yeah, but also the instruction itself was missing <janneke>dannym: i'm pushing WIP commits to mes wip and tcc branch mes-0.23 <janneke>dannym: the local/development had bitrotten (only the guix bootstrap.sh build still worked) <janneke>dannym: and also, was too x86 specific <janneke>dannym: for the arm instructions i'm kinda "guessing", hoping its okay --please have a sharp look <dannym>janneke: You have to reverse the endianness <dannym>janneke: Since we are targeting ARM little endian <dannym> DEFINE strh___%r4,(%r4) b040c4e1 # strh r4, [r4] <dannym>+DEFINE ldrsb__%r2,(%r0) e1d020d0 # ldrsb r2, [r0] <dannym>+DEFINE strh___%r2,(%r1) e1c120b0 # strh r2, [r1] <dannym>Like one always stores a 32 bit number into little endian slot <dannym>It's because M1 interprets e1d020d0 as the bytes e1, d0, 20, d0 <dannym>I asked Jeremiah back then to change it, but then thought better of it. It's easier to review if it doesn't do more complicated stuff than bytes <dannym>Also, it would not be backward compatible if we changed it now <janneke>anyway, i now have a segfaulting, gcc-built "./arm-unknown-linux-gnueabihf-tcc --help" <janneke>and...interestinly, a "somewhat working" "mes-tcc --help" <janneke>(that is to say, --help does not segfault, compilation of a minimal .c still does) <janneke>dannym: you'll notic that i switch back to using guile+mescc now -- faster and better error traces <OriansJ`>janneke: please let me know when you have a commit where mescc works well on guile so that I can snapshot it for mes-m2 <dannym>janneke: ldrsb r2, [r0] should be d0 20 d0 e1; strh r2, [r1] should be b0 20 c1 e1; strb r2, [r1] should be 00 20 c1 e5 <dannym>(I don't think it's allowed to have the spaces in M1 btw--it's just for clarity) <dannym>+// lib/gcc/arm-unknown-linux-gnueabihf/7.5.0/libgcc.a(_dvmd_lnx.o): in function `__aeabi_ldiv0': <dannym>+// (.text+0x6): undefined reference to `raise' <dannym>I was careful to name internal functions with preceding "__" <dannym>So our function is called "__raise" <dannym>I guess we can add a tcc compatibility shim for raise, or an alias or something <dannym>./lib/linux/x86-mes-mescc/syscall-internal.c:__raise(int signum) <dannym>./lib/linux/x86-mes-gcc/syscall-internal.c:__raise(int signum) <dannym>./lib/linux/arm-mes-mescc/syscall-internal.c:__raise(int signum) <dannym>./lib/linux/arm-mes-gcc/syscall-internal.c:__raise(int signum) <dannym>Or we could rename ours--but ehhh that's not nice, polluting the user namespace (would be OK for now I guess) <janneke>dannym: i have fixup'ed and reset WIP for the M1 instructions <janneke>OriansJ`: we're working (slowly) towards 0.23 which will contain some bugfixes but mostly ARM work <janneke>OriansJ`: 0.22 does not work for you? no harm in waiting for 0.23...not sure what you're looking for ;-) <janneke>dannym: about raise, i hesitated...but i guess there's no harm in moving {raise,getpid,kill} (if that's all?) from libc+gnu to libc+tcc <janneke>dannym: having that separation is of debatable value anyways... <dannym>janneke: If you move the actual function, you force using the rest of libc <dannym>janneke: Because they set errno, and errno is in libc <janneke>oh...yeah, the (if that's all?)-bit worried me <dannym>For example, it's like this (or should be): int raise() { status = __raise(...); if (status < 0) errno = -status; } <dannym>Just checked the manual page, raise() doesn't set errno <dannym>janneke: But kill() does. And we use kill in raise <dannym>janneke: I'd suggest to just use our __raise as "raise" and delete "raise" from ./lib/posix/raise.c <dannym>Otherwise that's just inviting weird complications <dannym>There's no prototype for "raise" in include/ in mes-wip btw <janneke>dannym: okay, let's try that (raising __raise to raise) <dannym>I'd still only introduce "raise" without "__" in the lib/linux/*-gcc directories <dannym>No reason to pollute the other ones <dannym>(By "pollute" I mean that then the user can't have a function "raise" in their programs anymore... even when he doesn't use libc...) <janneke>we can reconsider/add/pollute when the need arisese (prolly never) <janneke>dannym: would it be more handy if we push+reset wip stuff/branches to our gitlabs -- i hate to reset stuff you push to savannah -- wdyt? <dannym>syscall-internal is in libmescc, and presumably a gcc-built thing doesn't use both -lmescc and -lgcc <dannym>So I think that's why they don't have "__" before the "raise": They want the user to provide it <dannym>If you want, we can use gitlab--I don't care so much either way because I estimate there will be only very few ARM-specific changes now <dannym>At least to get the first release done <dannym>Later on I should do a lot of cleanup <dannym>janneke: What's the entire command line of this error-message-causing tcc compilation you have in lib/mes/div.c ? <dannym>@@ -169,4 +169,18 @@ __aeabi_uidiv (unsigned long a, unsigned long b) <dannym> return __mesabi_uldiv (a, b, 0); <dannym>+// arm-unknown-linux-gnueabihf-gcc -g -o arm-unknown-linux-gnueabihf-tcc -nostdinc -nostdlib -fno-builtin ... <dannym>+// lib/gcc/arm-unknown-linux-gnueabihf/7.5.0/libgcc.a(_dvmd_lnx.o): in function `__aeabi_ldiv0': <dannym>+// (.text+0x6): undefined reference to `raise' <dannym>Which libc is that arm-unknown-linux-gnueabihf-gcc invocation using? <dannym>It says nostdlib there, so obviously there won't be the libc posix raise() <janneke>dannym: arm-unknown-linux-gnueabihf-gcc -g -o arm-unknown-linux-gnueabihf-tcc -nostdinc -nostdlib -fno-builtin --include=mes-source/lib/linux/arm-mes-gcc/crt1.c -Wl,-Ttext-segment=0x1000000 -I . -I mes-source/lib -I mes-source/include -D inline= -D 'CONFIG_TCCDIR="usr/lib/tcc"' -D 'CONFIG_TCC_CRTPREFIX="usr/lib:{B}/lib:."' -D 'CONFIG_TCC_ELFINTERP="/lib/mes-loader"' -D 'CONFIG_TCC_LIBPATHS="usr/lib:{B}/lib:."' -D <janneke>'CONFIG_TCC_SYSINCLUDEPATHS="mes-source/include:usr/include:{B}/include"' -D 'TCC_LIBGCC="usr/lib/libc.a"' -D BOOTSTRAP=1 -D CONFIG_TCCBOOT=1 -D CONFIG_TCC_STATIC=1 -D CONFIG_TCC_LIBTCC1=1 -D CONFIG_USE_LIBGCC=1 -D TCC_MES_LIBC=1 -D TCC_TARGET_ARM=1 -D ONE_SOURCE=1 tcc.c libtcc1.a libc.a -lgcc <janneke>(note that i hacked/added a "raise" in div.c ...) <dannym>janneke: I know--but that will be a problem because now mescc and mes-libc can't be linked into the same program anymore <dannym>janneke: And that's what mescc does when you don't disable stdlib: link both <janneke>dannym: running: V=2 ./build-32.sh should give you that too <dannym>janneke: Because the mes-libc also has a "raise" function <dannym>janneke: But if there's this weird --include=mes-source/lib/linux/arm-mes-gcc/crt1.c thing, maybe put the raise in there? <janneke>dannym: build-32.sh has: cp $MES_SOURCE/gcc-lib/libc+tcc.a libc.a <dannym>Yeah, so we should add it to the libc+tcc too. But then you need kill and errno and so on, so lots of the libc. But it IS a libc--that shouldn't be a problem if that's in there :) <dannym>It's just that I had a lot of "fun" with errno back in the day when they made it thread-local in glibc (it had been global before), and now I'm wary of it. <janneke>+gnu: what binutils,gcc,gzip,tar... need more than tcc <dannym>Well, then I agree, we should just add raise, kill and so on to that libc+tcc as well :) <janneke>OK, reall just move them from +gnu (+gnu includes +tcc) <janneke>dannym: (--include could work, sort of, but this is really about using gcc-sans-libc usage, and wether or not to use -lgcc or have the __aeabi_* functions in div.c) <janneke>we want to be able to use gcc-sans-libc in mes too, to do testing <dannym>I only saw "-nostdinc -nostdlib ..." with the "...", so that looked like sans libc <dannym>So it's supposed to go there, of course :) <janneke>so, mes prolly has some build instructions for gcc-sans-libc that would need -lgcc added when we remove __aeabi_* from div.c) <janneke>it's cleaning up some weird thinking of mine that sublimated into source code <dannym>Btw, on mes-wip libc_tcc_SOURCES in build-aux/configure-lib.sh includes $libmescc_SOURCES. Is that on purpose? Shouldn't mescc link -lmescc anyway so this is duplicate? <janneke>dannym: that's a recent thinko: b5d7e1749 build: Include div.c in libc+tcc.a. <janneke>although i'm not sure about "lib/linux/$mes_cpu-mes-$compiler/syscall-internal.c"; shouldn't that be in libc+tcc, libc+gnu too? <dannym>No, that's the whole reason I split it off: for it not to be in libc <dannym>It's there because the division by zero thing wants to use raise(SIGFPE) <dannym>So I need to be able to emit the raise syscall <dannym>that means I have to be able to emit (some) syscalls even without libc <dannym>Because presumably one wants to be able to divide integers even when not using libc ;) <dannym>"internal" as in "internal to mescc"--it's only there for -lmescc use <dannym>It also reverted some copyright line update <dannym>Also moved raise, kill and getpid up to libc+tcc <dannym>Pushed 98e58796d6d85e55fb59cb416acc5a83b8847e64 to mes-wip to make __aeabi_idiv gcc-only (in preparation to removing it :)), and to not use __aeabi_idiv in the backend emitter <dannym>Reverted your adding of raise() to div.c in mes-wip now <dannym>Let's not support using mescc with -lgcc <dannym>Because some calling conventions in -lgcc mandate using registers for inputs <janneke>we can alwys take a stab at thet when we're getting extremely bored ;) <dannym>janneke: Could you take care of changing the build system so gcc always uses -lgcc and mescc always -lmescc ? At least if they are compiling a source that uses division ;) <dannym>janneke: After that, remove the entire block that starts with "#if __GNUC__ && !SYSTEM_LIBC && __arm__" in lib/mes/div.c <dannym>(that block introduces __aeabi_idiv, __aeabi_idivmod, __aeabi_uidivmod, __aeabi_uidiv) <dannym>janneke: (I mean mescc and gcc would add -lmescc and -lgcc, respectively, anyway unless you pass special options to disable it) <dannym>-nodefaultlibs: Disables -lgcc, I think <dannym>-nolibc: Leaves -lgcc enabled, I think <dannym>-nostartfiles: Leaves -lgcc enabled <janneke>right, so we could try -nostartfiles -nolibc -- althogh the doc says -nostdlib -lgcc / -nodefaultlibs -lgcc are also valid -- dunno :-) <janneke>tricksy to get all these just right, for all compilers, libc's and architectures... ***terpri__ is now known as terpri
<OriansJ`>bauen1: I have finished reviewing your change and have merged it into mescc-tools-seed; thank you for the 26byte reduction in AMD64's hex0 <bauen1>also shouldn't hex0 be part of the hashes in answers ? <bauen1>i'll probably work on a similiar thing for hex1 <bauen1>and adjusting things so memory written to is explicitly written out ***terpri__ is now known as terpri
<OriansJ`>bauen1: it could be but I haven't added them yet as I expected optimizations and reductions to occur prior to the completion of the bootstrap <dannym>janneke: Yeah, but I'm trying not to hardcode the name "-lgcc" - gcc could technically always rename it since it's an implementation detail (they probably won't...) <janneke>dannym: you have seen my gitlab mes-0.23 fixes? i'd hate for you to have to figure out that mess (again)