<OriansJ>fossy: you can steal the int to hex function in M1; it covers both big and little endian orders if you want <pder>stikonas, fossy: This was the least invasive workaround I could come up with to fix the problem with output from our tcc+musl binaries truncating output when redirected to a file or pipe. <pder>Yeah, I tried removing that patch, and they fixing up missing symbols in tcc, but then I got a whole bunch more when proceeding on to m4 <stikonas>I tried to add some object files to tcc and it linked fine, but then I was getting more problems as I went further <pder>The problem is complicated with how weak symbols behave differently with static linking and the fact that I dont know if tcc ar is doing the correct thing <stikonas>pder: by the way, which version of perl you were playing with? <pder>Not sure why I picked it <stikonas>well, 5.32.0 us the latest stable version... <OriansJ>well looks like PPC64le has little endian instruction encoding <vagrantc>isn't that what the "le" is about, or is it a lot more complicated than that? <OriansJ>vagrantc: you can have Big endian instructions and little endian data (x86/AMD64) <OriansJ>and can get even messier (big endianness mismatches) *vagrantc remembered when the armel architecture on debian was the new thing from the old "arm" architecture <vagrantc>that was perhaps my first exposure to the idea of endianess <OriansJ>bit endianness which makes things even more messy <OriansJ>dftxbs3e: yes but I'm still behind where I need to be (starting to write a proper ELF header for PPC64le and a good hello world in hex) <vagrantc>i seem to recall a number of providers that give free access to POWER9 systems for working on free software projects, i can dig up links if interested <dftxbs3e>vagrantc, they wanted baremetal access, OSUOSL or minicloud only gives VM AFAIK <OriansJ>PowerPC does not make PC-relative loads easy. <dftxbs3e>OriansJ, is there a readable PC register? <dftxbs3e>Or it is like x86 you need to use the call instruction to extract it? <OriansJ>dftxbs3e: not sure yet, digging into the documentation and playing with the gnu assembler to try to find something useful <OriansJ>bl 0x4 and mflr might provide that behavior but it'll also override the link register <OriansJ>so I'll have to push the link register before it and pop the link register after it <OriansJ>but PowerPC doesn't have push and pop just store and load with increment and decrement <dftxbs3e>yes :-S and like a 64-bits register load is two 32-bits load with one 32-bits shift register - didnt seem to be made to be written by humans <OriansJ>dftxbs3e: certainly not human friendly but I'll shove it into a working solution <OriansJ>even if it means I have to do 12 things just to load a 64bit immediate. <OriansJ>but thus far I am very good at segfaulting on PowerPC64le <OriansJ>it is very touchy about: .section ".opd","aw" <OriansJ>have no idea what it actually means yet <OriansJ>nothing I try seems to result in anything but segfault <OriansJ>the command in hex2 to build: hex2 --little-endian -f elf64-PowerPC.hex2 -f foo.hex2 --base-address 0x10000000 -o foo <OriansJ>I'm probably missing something important, I just don't know what yet <OriansJ>so I am going to get some sleep and try again tomorrow (hopefully I can figure out how to even execute a single instruction [even if wrong], rather than just segfaulting on every load attempt) <dftxbs3e>OriansJ, will take a look but also a beginner in PowerPC assembly, only know x86 well, sleep weel ***mephista is now known as spicy_icecream
<OriansJ>gforce_de1977: well that is why I have 00 00 01 00 00 00 00 00 ## Required alignment; aligned to 0x10000 which will put it exactly on a page <OriansJ>but just in case the 78byte elf header is throwing things off I can double null pad <OriansJ>oh and for those wanting to do the same dev environment as me: qemu-system-ppc64 -m 1024 -smp 1 -boot menu=on -drive file=prototype.qcow2 -net user,hostfwd=tcp::666-:22 -net nic (install debian PowerPC64le, only ssh-server and build-essentials+gdb) <stikonas>pder: I've just checked, I think perl 5.8 is the latest we can try to build <stikonas>newer perl's have even greater dependency on perl itself <stikonas>(we might build newer later once we bootstrap something) <stikonas>(perl seems to do some postprocessing after perly.y->perly.{c,h} <pder>stikonas: what part of autotools needs perl and how extensively? I am wondering if perl could be skipped for now? <pder>doesn't guix build binutils and gcc before perl? <pder>Just checked Linux From Scratch, and version 5.1 of it uses bash-2.05b like us and perl 5.8.4 <pder>Also autoconf 2.59 and automake 1.8.4 fwiw <stikonas>and I guess perl doesn't care about pre-generated files <stikonas>but I guess we only need perl executable, not 20 or so that perl provides... <stikonas>by the way, I did two runs of live-bootstrap, all binaries had identical checksums <stikonas>so I think for now live-bootstrap is reproducible <Hagfish>it might seem excessive, but you could automate that process and make it a condition of a clean build