IRC channel logs
2025-05-22.log
back to list of logs
<stikonas>we could extend builder-hex0, but that's harder <stikonas>instead of append, maybe we could read the whole file and output the whole thing then? Probably a bit slower <matrix_bridge><Jeremiah Orians> Well nothing in mescc-tools-extra should be using append <fossy>pder: ooh thanks for testing, I have not tested live-bootstrap with latest stage0-posix yet, so you are first to do so probably <fossy>yes, we will need to change that <matrix_bridge><Jeremiah Orians> Well blood-elf is not going to like separate .o files but we could use catm to merge them together prior to that <matrix_bridge><Jeremiah Orians> So I should be able to change it to just determine if there are linked files with .o and if and only if they exist do an additional exec call <oriansj>gtker: you may need to double check your test0004 as you appear to be trying to involve linking libc.o with assembly files that don't have a main function which wouldn't work <oriansj>but it appears a prior commit f1d26a7d introduced a bug which means that -I doesn't work and #include doesn't find the M2libc needed because the path becomes a constant static value. <oriansj>I think you ment to add a change to cc_reader.c (probably around line 396) and leverage the access syscall to figure out which of the paths has the library in question and then use the first found. <oriansj>if you don't get to it, I'll probably do it later in the weekend <matrix_bridge><gtker> stikonas: Changing it in M2-Mesoplanet would also make it work for UEFI, although it would either require a sufficiently large buffer or file juggling. Could append be added to the builder-hex0 kernel, or would that be annoying to do? <matrix_bridge><gtker> oriansj: I worked around blood-elf on multiple files so it should work correctly, although I don't think the feature really takes much weirdness before it breaks. The way we include the definitions of libc in the header files most definitely breaks everything <matrix_bridge><Jeremiah Orians> Well we could do a libc behavior change when we do -c <matrix_bridge><gtker> That's true, but we would also somehow need to get the definitions in when doing the "linking" <matrix_bridge><Jeremiah Orians> Well the .h files would have the prototypes and that bit would remain, only we would have M2-MesoPlanet skip the .c parts #included under the -c conditions only <matrix_bridge><Jeremiah Orians> Perhaps a variable for the #if blocks which is set only if we are doing -c <matrix_bridge><gtker> I also considered embedded metadata in the -c M1 files but couldn't really settle on the best way of doing it <matrix_bridge><gtker> Then I got sidetracked and now I'm working on a GAS compatible assembler buildable with cc_* <matrix_bridge><Jeremiah Orians> Well you could just put #include in the M1 files as # is a line comment <matrix_bridge><gtker> Hmm, and then include the .c files in the last step? <matrix_bridge><Jeremiah Orians> Well it would not be hard to get M1 to support a —link flag that looks for #include and tracks which have already been added <matrix_bridge><Jeremiah Orians> Also I suggest doing the GAS compatible assembler in the M2-Planet v1.x subset as it would be much easier <matrix_bridge><gtker> I've been doing some work on M2-Planet in the cc_* subset and I honestly don't think it's that limiting, so I might as well use it 🙂 <matrix_bridge><gtker> Would also allow M2-Planet to use it directly without intermediate steps <matrix_bridge><Jeremiah Orians> Fair enough, I tried to make cc_* as powerful as possible with as few C features as possible <matrix_bridge><gtker> It's very well done. At first I didn't even realize that "&"/"*" weren't possible since they aren't really needed as long as you're using datastructures that don't need them <matrix_bridge><gtker> Only thing I'm missing is to ignore "__attributes" for functions since GCC allows extensions that change how the warnings identify possible use after free and null pointers <matrix_bridge><gtker> Don't think it's possible with ifdefs or pragmas since the attribute would still need to be on a separate line <matrix_bridge><Jeremiah Orians> Well give the community some time and someone else might figure out a solution <matrix_bridge><Jeremiah Orians> I honestly was surprised your cc_* solution which removed the need for CONSTANT. Brilliant work <matrix_bridge><gtker> Ha, thanks 🙂 Humorously the first thing I added to M2-Planet was enum support and the first thing I added to cc_* was also enum support <matrix_bridge><Jeremiah Orians> Lots of brilliant, wonderful, kind and talented people here with novel perspectives and insights which really moved the whole project years ahead of where I thought we would be at this point <matrix_bridge><Jeremiah Orians> And I am excited to see your GAS assembler as that would be a major leap in our C compatibility toolkit <matrix_bridge><gtker> I'm working on the aarch64 version right now. It's going to be a huge job just adding those instructions but I'm guessing we'll only really need the most useful ones. I'm planning on calling it done when it can compile the GAS versions in stage0-posix-aarch64 <matrix_bridge><Jeremiah Orians> Correct, a minimal subset would be plenty as we can just add more if and only if we find something needs it