***terpri_ is now known as terpri
<dannym_>janneke: Yeah, the startup is thumb-incompatible... <janneke>dannym_: ah, thumb is default -- weird :) <dannym_>janneke: (mostly because all the upper registers are not available in thumb) <dannym_>janneke: Well, Thumb takes less space. With todays caches that means a real speedup because the OS doesn't have to evict the program from i-cache all the time... <dannym_>janneke: But for bootstrapping, I think ARM is better to use simply because it's older and even ancient ARM machines can do (mostly) the same instruction set <janneke>dannym_: sadly, i found that the 32bit gcc-built tinycc runs on the banana, but not under qemu-binfmt <dannym_>janneke: I hate those qemu incompatibilities <dannym_>janneke: I thought I had avoided all of those by now :P <janneke>also, the qemu-binformat-built executable does not run on banana (i haven't tried to bisect object files or anyting -- there /are/ differences) <dannym_>janneke: I sometimes abuse qemu-internal debugging feature for finding the reason: -d nochain,in_asm,cpu <dannym_>janneke: It will print the assembly as it is JIT compiling it <dannym_>janneke: It's not perfect because if it already had the block (in a loop etc) it won't print it again because it already JIT-compiled it (duh) <dannym_>janneke: Or just gdb on banana, might be easier :) <dannym_>I can also have a look on it of course :) <janneke>dannym_: OK -- i'm trying to let most ARM work to you ;) <janneke>but i like to stay involved and esp. help with non-arm stuff & bugs <janneke>but for the rest it should build using "./doit" <dannym_>janneke: I'm disentangling libc and libmescc, changing where the syscall implementation a tiny bit again, on mes-wip <dannym_>janneke: After that, it should be possible to use mes-built libc without mescc.a <janneke>dannym_: yeah, such incremental insight is mainly why i have come to only push to wip-* commits master after the guix bootstrap succeeded again ;-) <dannym_>janneke: Pushed that to mes' wip on savannah as commit d86aa5c5891ea146339174068e027a7ab1c08a48 <janneke>dannym_: whoa yea -- i didn't mean that as criticizm; i'm merely sympathizing with how difficult it can be to oversee such changes <janneke>dannym_: i made many of such changes that seemed like a good idea, esp. "simple" once in include headers <janneke>i dread the "extern" change that we may need to make for gcc 10 to avoid multiple definition errors ***terpri__ is now known as terpri