channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev&y=19&m=5&d=1
12:59:06 <keegans> having some strange issues with qemu and my os that i'm building -- specifically if i enable the vga cursor, for example, i can see the cursor flash as soon as it boots, then the cursor disappears permanently
12:59:26 <keegans> as well, if i clear any character using the WriteCharacter function as provided on the osdev wiki, it will ONLY clear the first character in vga text mode
12:59:43 <keegans> e.g.: WriteCharacter(' ', 7, 0, 3, 0); has an identical effect as WriteCharacter(' ', 7, 0, 0, 0);
01:08:18 <doug16k> the foreground and background are the same right? memset to zeros or something?
01:09:19 <doug16k> oh in qemu I don't know if it even tries to blink it
01:10:07 <doug16k> keegans, do you have a link straight to that code?
01:10:37 <keegans> yeah but it seems that something much bigger is at play ... if i do something like comment out a function in the C file , i get completely different results ...
01:10:48 <keegans> which means i've got something funky going on with memory alignment or something like that
01:10:58 <doug16k> what arch?
01:11:01 <keegans> i'll send a link to the code gimme a sec
01:11:05 <keegans> x86
01:11:18 <doug16k> do you make sure you have a 16-byte aligned stack before you enter compiled code?
01:11:35 <doug16k> really weird stuff can happen if you don't do that
01:12:03 <keegans> no i just jump right into the C code
01:12:08 <keegans> ;p
01:12:14 <doug16k> the compiler will assume things about esp extremely heavily
01:12:34 <keegans> ah
01:12:35 <doug16k> if you got it wrong the code it wrote won't always work
01:13:24 <doug16k> it will do funny things to esp that work because it "knows" it was aligned a certain way
01:13:52 <doug16k> because the ABI says you must make calls a certain way
01:14:31 <keegans> i'll send code to illustrate one second
01:15:07 <keegans> https://gist.github.com/meme/1e06ee2e1d43a0e26c560024ea248b40
01:16:00 <doug16k> break into it in a debugger and disassemble it
01:16:07 <doug16k> compare that to what objdump -S says
01:17:17 <doug16k> and/or, put a breakpoint on the very first instruction of the void main (void??) and make sure esp has a C in the lowest hex digit
01:18:17 <eryjus> keegans, check your port_byte_out and port_byte_in implementations -- i have seen problems with those create odd issues before
01:18:40 <keegans> ah eryjus the issue is not that function (notice how it isnt called )
01:18:43 <keegans> but rather that it is present
01:18:44 <doug16k> good idea. those could be catastrophically wrong easy
01:18:51 <keegans> 00000097 <main>: vs. 00000000 <main>:
01:19:31 * eryjus nods
01:20:04 <doug16k> which one is 0?
01:20:33 <keegans> https://gist.github.com/meme/1e06ee2e1d43a0e26c560024ea248b40#gistcomment-2902911
01:20:40 <eryjus> hmmm... entry point on your link script?
01:20:42 <doug16k> hard to believe a compiler put function entry at offset 7
01:21:00 <doug16k> (7 from a fetch window boundary)
01:21:30 <keegans> gcc w/ -ffreestanding -m32 -fno-pie -fno-stack-protector linked w/ ld -melf_i386 -Ttext 0x1000 kernel.o --oformat binary -o kernel.bin
01:22:02 <doug16k> w/ ?
01:22:08 <keegans> with
01:22:13 <doug16k> ah
01:22:15 <keegans> like how im compiling these things i mean
01:22:50 <doug16k> need -g
01:23:06 <doug16k> same when compiling/assembling
01:24:18 <keegans> how will the debugging info help us here, sorry if i am misunderstanding
01:24:28 <doug16k> oh I just saw your disasm
01:24:40 <doug16k> show your port functions
01:24:52 <doug16k> source code
01:24:56 <keegans> yep one sec
01:25:14 <keegans> https://gist.github.com/meme/1e06ee2e1d43a0e26c560024ea248b40#file-port-c
01:25:53 <doug16k> I'd make those asm's volatile too
01:26:03 <keegans> ah , will do
01:26:06 <doug16k> you do not, ever, want it to duplicate it as if it is idempotent
01:26:46 <elderK> GUYS! I GOT THE JOB!
01:26:52 <elderK> :O
01:26:53 <doug16k> elderK, nice!
01:26:59 <elderK> Holy crap! :O :D
01:27:11 <elderK> I start basically as soon as study ends.
01:27:23 <elderK> They don't even care if I graduate or not :O
01:27:33 <doug16k> keegans, can you add objdump -p -h your-program
01:27:58 <elderK> This interview was not what I was expecting - I was thinking there'd be more, as the recruiter said, but it was just this. It wasn't one person, it was several. It was a lot more involved than I was expecting
01:28:27 <keegans> https://gist.github.com/meme/1e06ee2e1d43a0e26c560024ea248b40#gistcomment-2903070
01:28:27 <doug16k> they did rotating interviewer thing eh?
01:28:30 <doug16k> it's common
01:28:48 <keegans> this is the of the object file, is that what you wanted ?
01:28:49 <doug16k> I like it too
01:29:10 <doug16k> keegans, when you load that, do you relocate it?
01:29:30 <keegans> well i link these
01:29:35 <keegans> using ld
01:29:40 <keegans> to a freestanding binary
01:29:47 <doug16k> you load it actually at 0xb6?
01:29:53 <keegans> no
01:30:04 <keegans> `-Ttext 0x1000` with `ld`
01:30:12 <doug16k> it didn't do that
01:30:24 <elderK> doug16k: Yeah they did, literally. It was video interview.
01:30:28 <keegans> well yeah i sent the objdump of the kernel object file not the produced flat binary
01:30:44 <elderK> :D Gosh. What an unexpectedly awesome thing :)
01:30:45 <elderK> :D
01:30:48 <doug16k> that is useless. do same with the linked executable
01:30:54 <keegans> will do
01:31:20 <keegans> but -p prints object file format information
01:31:26 <doug16k> ah it does say kernel.o right there. should have saw immediately :)
01:31:26 <keegans> and this produced binary is not an ELF object
01:31:47 <keegans> oh my goodness
01:31:49 <doug16k> -p shows program headers
01:31:49 <keegans> am i really this dumb ?
01:32:00 <keegans> -melf_i386 is producing an ELF file , yeah
01:32:11 <keegans> ok no no no
01:32:14 <keegans> i didnt make that mistake ok phew
01:32:39 <doug16k> it will show program headers then dump .dynamic records if any
01:33:58 <keegans> i'm not understanding entirely, if i have a bunch of freestanding .o elf object files, and i link them into a raw binary file which just contains the raw assembly, how will i be able to print elf information
01:34:09 <keegans> the only usage of elf here is just for the intermediate objects
01:34:10 <doug16k> oh
01:34:16 <doug16k> link it again without that binary thing
01:34:23 <doug16k> then objdump that
01:34:29 <keegans> ah ok
01:34:38 <doug16k> you need that already, for debugging
01:34:56 <doug16k> you point gdb at the elf, load the binary however, attach debugger, bingo
01:35:19 <keegans> ah i wasn't sure how to debug this kind of stuff
01:35:20 <keegans> https://gist.github.com/meme/1e06ee2e1d43a0e26c560024ea248b40#gistcomment-2903159
01:35:23 <keegans> that makes sense, though
01:35:25 <doug16k> attach debugger can be anywhere in the order
01:36:50 <doug16k> note.gnu.property 0000001c 080480f4 080480f4 000030f4 eh?
01:37:21 <doug16k> what is that doing there at 0x480f4 funny place
01:37:54 <doug16k> how big is that bin file? > 4MB?
01:38:03 <doug16k> oops
01:38:06 <keegans> 14k
01:38:08 <doug16k> >256KB?
01:38:13 <zid> >1203TB!?
01:38:27 <zid> sorry I just wanted to fit in
01:39:52 <keegans> its 14k
01:40:19 <doug16k> keegans, how about: objdump -b binary --adjust-vma=0x1000 your-bin-file
01:40:28 <doug16k> oops, -D before the filename
01:42:17 <keegans> what about the objdump ?
01:42:48 <doug16k> disassemble the bin file
01:43:00 <doug16k> see if it is a bunch of zeros or some crap before your code
01:43:17 <doug16k> that's what ends up in memory if it actually loads it at 0x1000
01:43:42 <doug16k> I've seen weird things where it puts zeros up to your start address
01:43:50 <doug16k> in your case it'd be 4096 0's
01:44:22 <doug16k> gold and bfd do different things
01:44:56 <keegans> first instruction is a 1000: 7f 45 jg 0x1047 which seems not right
01:45:06 <keegans> oops `jg 0x1047`
01:45:09 <keegans> is what i meant
01:47:26 <doug16k> check hexdump -C your-bin
01:47:35 <doug16k> begin with 7f 45?
01:48:34 <keegans> i mean yeah it's an ELF
01:48:37 <keegans> oh
01:48:39 <keegans> lol
01:48:43 <doug16k> bin
01:49:06 <keegans> oh look
01:49:17 <keegans> `00001000 <vga_enable_cursor>:`
01:49:22 <keegans> `00001097 <main>:`
01:49:36 <keegans> but i mean my bootstrap.S code calls main
01:49:48 <keegans> `[extern main]`, ` call main`, `jmp $`
01:50:07 <keegans> ah but the bootstrap.S code is not at the 1000 address
01:50:23 <keegans> how the heck did this work at all in the first place
01:50:29 <keegans> ah i guess when the main function was the only one it did
01:50:36 <keegans> but just out of sheer luck
01:50:36 <doug16k> the bin loader loads it there and jumps/calls 0x1000?
01:50:50 <keegans> it calls main, so it resolves to the right address
01:50:52 <doug16k> that's what makes it so hard. it can be utterly wrong and work
01:50:53 <keegans> the kernel jumps to 0x1000
01:51:02 <keegans> so yeah this makes sense now
01:51:21 <keegans> but im not sure how to have the call main be right at the 0x1000 address with ld
01:51:49 <keegans> but wow
01:51:54 <keegans> thanks for your help
01:53:23 <doug16k> keegans, you can make the compiler put a function in a specific input section. then you need a linker script though
01:53:44 <doug16k> you can coerce it to put the main in .text.main then in your linker script, put a gun to its head to put that at the beginning of .text
01:54:11 <doug16k> __attribute__((__section__(".text.main")))
01:54:14 <doug16k> IIRC
01:54:28 <keegans> yeah so pretty much i have my bootstrap.S which has the `call main` and main is relocated by the linker
01:54:36 <keegans> but then i want that relocated call to be right at 0x1000
01:54:46 <keegans> so that my main can be at any arbitrary address
01:54:59 <doug16k> ya, if you force main to be at the beginning of .text, it will be at 0x1000 coincidentally
01:55:16 <keegans> ah so then i dont even need the bootstrap.S
01:55:17 <doug16k> assuming .text is the first section in the bin
01:55:17 <zid> that sounds like relocating "call main" but with an extra unneeded step to me
01:55:20 <keegans> is that an ok solution ?
01:55:26 <keegans> ok yeah i will use that instead then
01:55:28 <keegans> thank you
01:55:33 <keegans> i just wasnt sure what the best way was
01:55:42 <keegans> but if i can have gcc force it to be at 0x1000 that works best
01:55:59 <doug16k> when you are this close to the metal you often want some "beginning" stuff to be at the beginning naturally
01:56:22 <doug16k> no arbitrary entry point somewhere in there, just jump to beginning and call it a day
01:56:35 <doug16k> let that module have a stub there to jump somewhere
01:56:44 <zid> or give it a header.S
01:56:58 <doug16k> I mean you already decided to do that by making it a bin file. nowhere to put an entry point
01:58:00 <doug16k> it's not the only thing you could do, but it least violates the principle of least surprise
01:58:39 <keegans> wait so is there any way to do this without a linker script , then ?
01:58:57 <keegans> i know what i need to do just not the best way to do it
01:59:03 <doug16k> make sure you put the object file with the entry point at the beginning
01:59:21 <doug16k> that should make it coincidentally land first
02:00:22 <keegans> well i think not coincidentally because yeah the linker respects the order
02:00:34 <keegans> ok yeah i believe that will work best
02:01:01 <doug16k> I say coincidentally because it is just a coincidence that the first object file is also the entry point
02:01:38 <keegans> ah i see yeah
02:02:48 <keegans> perfect, yup. looks good now in objdump
02:02:54 <keegans> thank you very much for your help , learned a lot too
02:03:04 <doug16k> when two things in code/whatever need to be the same, and nothing is making them the same other than humans making sure, I call that a coincidence. nothing is enforcing it
02:03:06 <doug16k> np
02:04:50 <keegans> yay now everything works properly !! very nice
02:04:55 <doug16k> you could provide startup code and make the build system link those bin files a particular way and strictly control where things land, and it wouldn't be a coincidence then
02:05:11 <doug16k> nice
02:07:59 <keegans> ok have a nice day or night
02:08:20 <keegans> i will add my irc bouncer here as well as im sure i will have more questions
02:08:25 <keegans> thanks again
02:43:50 <doug16k> instead of riding along as a passenger as the toolchain drives through fences and backyards, I like to grab the controls and drive it :)
11:01:57 <bauen1> glauxosdever: i see what you're problem is, i now have a "good" build system, an os-specific toolchain but only ~20 lines of kernel code ._.
11:15:00 <hgoel> ended up starting work on a custom programming language since it'd be the easiest way to work on the user mode for my current os design, for once I actually managed to get past the parser stage
11:15:50 <hgoel> after properly writing out the bnf I just wrote a little program to spit out the recursive descent code
11:17:09 <hgoel> it's all in C#, which my language is similar to, so the idea is that it'll only take a bunch of refactoring to make it self hosting
11:24:05 <glauxosdever> hgoel: Cool! I'm also considering doing some language design (before doing the OS), but for now I've left efi.h in the middle (or rather at around 20%), my curiosity about CPUs has returned, and I have some assignments for the university
11:24:27 <glauxosdever> hgoel: What features will your language have?
11:25:08 <glauxosdever> I see you mentioned C#, but then again I don't know much about it
11:25:54 <hgoel> it's basically C but with additional sugar for the object model (to keep things clean) and slightly stronger type safety
11:26:27 <hgoel> it's not exactly object oriented though
11:26:58 <hgoel> kinda designed specifically for the os
11:27:05 <bauen1> please add namespaces
11:27:34 <hgoel> yeah, it sort of has that
11:27:43 <bauen1> nice, that is one of the most lacking things in C
11:29:03 <hgoel> the language is basically entirely worthless outside of my os so...
11:29:44 <glauxosdever> hgoel: Please make sure the compiler can know what pointers should point to, e.g. in C you have "char*". Is it a pointer to a single char? A pointer to an array of 10 chars? A pointer to an array of chars that's of unknown length? Possibly support for NUL-terminated char arrays (where the compiler knows the last actual element there is a NUL or some other value)?
11:29:54 <glauxosdever> Maybe it's too hard to do that
11:30:23 <hgoel> that wouldn't really make sense since it's all just data
11:30:42 <hgoel> what I am doing is not using plain pointers
11:30:43 <glauxosdever> It would be good for type safety
11:31:42 <hgoel> yeah, I intend to have 'pointers' be done through arrays, the address and range being passed to an standard function
11:32:08 <glauxosdever> Fat pointers are also good when concerned about type safety, but I'd consider shifting it more to compile-time, whenever possible
11:32:13 <hgoel> and similarly a standardized function to do an in-place cast
11:32:44 <hgoel> well it's almost definitely going to JIT on the system anyway
11:32:56 <hgoel> I think, not sure yet
11:33:15 <hgoel> going to end up needing an assembly backend anyway so it isn't a huge deal
11:34:13 <hgoel> but yeah, a JIT system would also make it easy to 'update' applications without having to recreate the object, so it'd be ideal
11:34:30 <hgoel> the compile time approach would be a bit more tedious
11:34:43 <glauxosdever> But JIT is some orders of magnitude slower
11:35:39 <hgoel> JIT's can be optimized to get very close, and really, that's more than enough
11:35:59 <hgoel> I can't afford to waste time worrying about every bit of performance
11:38:53 <hgoel> my main concerns are security and stability, performance just needs to be 'good enough' on a ~2015 midrange laptop
11:40:58 <bauen1> hgoel: will you implement exceptions ?
11:41:18 <hgoel> not sure tbh
11:41:45 <bauen1> i personally find rusts lack of exceptions quite nice (since you will actually have to handle the error appropiately), but there is quite a lot of discussion about them
11:42:21 <bauen1> eg. how would you express a division by zero if you don't (want to) have exceptions
11:43:44 <hgoel> hmm valid point, I would say by sending an appropriate signal, but since that wouldn't really fit with my os design, having at least basic exceptions might work better
11:44:59 <hgoel> alternatively I could immediately abort the rpc call and return a divide by zero error
11:45:04 <bauen1> i haven't tried it, but you could replace exceptions with something similiar to Maybe (from functional programming)
11:45:27 <hgoel> and expect developers to handle stuff like that themselves
11:45:32 <hgoel> I'll look into it
11:45:49 * glauxosdever would stick mostly to C principles; except for namespaces, better pointer syntax (including function pointers), no pointer/array confusion, inclusion of stdbool.h/stdint.h types in the base language (not headers), stronger typing, possibly a module system to get rid of the preprocessor, possibly some other small stuff
11:46:10 <glauxosdever> Otherwise, I'd keep it close to C
11:46:47 <bauen1> i would love if some of the gcc attributes would make their way into the C standard (like noreturn did)
11:47:33 <hgoel> why would you want to get rid of the preprocessor
11:47:54 <glauxosdever> Because it's ugly
11:48:09 <bauen1> also include files are mostly duplicate code (and sometimes documentation)
11:48:22 <hgoel> it's pretty elegant imo
11:48:31 <glauxosdever> #define SUM 12 + 8, then you do SUM / 2
11:49:08 <hgoel> well, #define SUM (12 + 8) and issue solved
11:49:16 <glauxosdever> Well, you forgot that!
11:49:24 <glauxosdever> (Anyone = "you")
11:49:35 <glauxosdever> Not you specifically
11:49:36 <zid> It's possible, not but likely
11:50:13 <hgoel> I always put parens around my macros out of sheer habit
11:50:45 <zid> I happen to know how macros work
11:50:51 <zid> so I just think about it as I write them
11:50:54 <zid> like I do with all my code
11:51:14 <hgoel> they're just as open to pitfalls as the rest of C tbh
11:51:31 <hgoel> but in exchange you get a ton of flexibility
11:52:52 <hgoel> plus, once you have to deal with the very minimal 'preprocessor' of C# you begin to really miss the one in C
11:53:14 <glauxosdever> Right. Today I wrote some code using pthreads and I did #define NTHREADS 4, then #if NTHREADS == 1 /* Single threaded code */ #elif NTHREADS > 1 /* Multithreaded code */
11:53:28 <glauxosdever> So maybe the preprocessor should stay despite being ugly
11:54:00 <hgoel> mhm
11:54:44 <glauxosdever> I could write two files sure, but for small programs it just doesn't make much sense
11:56:31 <immibis> bauen1: if your division function returns a Maybe then how do you get the value out of the Maybe?
11:56:45 <immibis> you can pattern match it. what do you do if the division returned Nothing?
11:57:27 <immibis> you can return another Nothing from your own function (or Left "division failed!")
11:57:40 <immibis> what good is that? it's no better than an error code
11:58:05 <zid> Thank god for UB
11:58:36 <hgoel> oh yeah, that's it! I'll just leave it as UB lol
11:58:53 <bauen1> immibis: you wouldn't use Maybe, but some construct that returns an abitrary value or an error value
11:59:11 <immibis> you still have to check it
11:59:12 <glauxosdever> For division, the compiler could make sure it's not a division by zero
11:59:15 <hgoel> with a sanitizer style approach like with ubsan for debug mode
11:59:31 <bauen1> the compiler could also force you into checking it isn't a division by zero
11:59:33 <immibis> so you want to do something like: start+(end-start)/2 - since you only have a checking division operator, what do you do with the result from /?
11:59:49 <immibis> (the / operator doesn't know that the 2 is always 2)
12:00:12 <glauxosdever> E.g. in a if (b != 0) block or a loop where you divide by the index and the index never is 0
12:00:54 <bauen1> immibis: static analysis, if the compiler still can't figure it out, it will yell at you (eg. using a non constant)
12:01:13 <bauen1> actually, it really depends on how you implement /
12:01:18 <immibis> so formal verification
12:01:18 <bauen1> and if you support operator overloading
12:01:46 <hgoel> that's a lot of complicated analysis to do too
12:02:03 <bauen1> true
12:02:11 <bauen1> undefined behaviour is easier
12:02:17 <glauxosdever> That's not exactly formal verification; formal verification is a method where you compare the code against a specification
12:02:26 <hgoel> yeah lol
12:02:40 <bauen1> but it also allows you to shoot yourself in the foot
12:02:59 <bauen1> why can't we figure out the value of x/0 already ...
12:03:13 <glauxosdever> That's an error
12:03:19 <hgoel> for sure, but that's why we can enable error reporting for debug builds
12:03:46 <glauxosdever> And what if this path is almost never taken during testing with debug builds?
12:03:58 <glauxosdever> And you don't happen to catch it?
12:04:16 <hgoel> well, rip, considering the point of debug builds is to test edge cases
12:04:23 <bauen1> glauxosdever: the only real way to implement correct testing is formal verification, which is a bit of beast (even more so if you're not using a functional language)
12:04:25 <glauxosdever> But I know it's very hard to check everything
12:04:37 <hgoel> if it's missed, the rpc errors out and gets reported to the calling task
12:05:01 <hgoel> (equivalent to process crash, but not exactly)
12:06:42 <hgoel> debugging then can be as simple as inserting a debug layer in front of the object, and if/when it errors out, the debug layer can generate a full report + process state for testing
12:08:23 <hgoel> could even just introduce a sort of global error tracker, which can automatically manage errors per object, since everything is signed and unforgeable anyway
12:08:37 <zid> errno is an option
12:08:48 <zid> to check if any division/whatever exceptions happened
12:09:11 <zid> so only code that wanted to know if the result was 0 or nan etc would check ferrno
12:09:12 <hgoel> not really referring to errno, but yeah, similar idea
12:09:27 <zid> you were talking about handling /0 without exceptions, I thought
12:09:36 <bauen1> errno always seemed like a design flaw to me, if you're already know that an error has happened, you might aswell return the error and not -1 and set errno
12:10:42 <hgoel> yeah, but errno doesn't really 'fit' since my os doesn't really do threads
12:11:01 <zid> threads?
12:11:03 <glauxosdever> bauen1: Agreed (forgot to mention that previously). For functions returning pointers, I'd pass a pointer to the pointer as an argument, so it can return "errno"
12:11:04 <hgoel> I suppose it could still provide a similar error value somewhere though
12:11:14 <zid> You'd just handle the exception and write to that tasks's errno variable
12:11:19 <zid> with what the exception was
12:11:31 <hgoel> yeah
12:12:09 <hgoel> tough choices lol
12:13:28 <glauxosdever> That's why we are here, and not somewhere where the only choices are whether to use AngularJS or React..
12:13:31 <glauxosdever> :-)
12:14:27 <hgoel> ok yeah, definitely won't use regular exceptions, instead I'll add an errno variable along with other error information, that should integrate nicely with having a sort of debug layer too
12:14:41 <hgoel> haha
12:14:49 <zid> I'd have just made it UB :P
12:14:51 <glauxosdever> hgoel: Or just have functions return an error value if they fail
12:14:59 <zid> division can't return a value
12:15:19 <glauxosdever> Wait, forgot we are talking about division here
12:15:24 <glauxosdever> :-)
12:15:42 <hgoel> haha
12:16:04 <zid> ofc C++'s decision was to make it even more impossible
12:16:15 <glauxosdever> bbl
12:16:18 <zid> by making things like "ask user for input" not be able to return values
12:16:26 <zid> ever tried to error handle cin? :p
12:16:37 <hgoel> hmmm, I think I'll leave overflow/underflow as UB though
12:16:38 <hgoel> oof
12:18:14 <hgoel> null references and array bounds are already taken care of too, I think that's all the main UB covered?
12:18:29 <zid> weird oeprations on signed values
12:18:34 <zid> mod, shift, etc
12:18:44 <zid> pointers to various things
12:19:11 <zid> like, are you allowed to point to non-objects, can you point before objects if you can't, can you point one past the end
12:19:25 <hgoel> I don't have C style pointers, so all those get handled at runtime
12:19:29 <zid> okay
12:21:12 <hgoel> and I think I can try to handle out of bound shifts if I can detect them at compile time, otherwise just leave them as UB, with debug builds inserting an explicit check for the bounds
12:23:56 <zid> hgoel: What does -4>>1 even do?
12:24:55 <zid> -2? or 2147483646? :p
12:26:28 <zid> or both and you have asr and lsr? :P
12:28:28 <hgoel> ah, sign extension
12:28:34 <hgoel> so -2
12:29:07 <hgoel> hmm
12:29:10 <hgoel> one sec
12:30:46 <hgoel> yeah, definitely just sign extending when it's a signed type
12:31:28 <zid> what about 1>>-1?
12:32:20 <hgoel> ub if it can't be checked at compile time
12:33:19 <zid> what does char a = 0xFFF; do? idb?
12:33:22 <zid> ub? truncate?
12:33:39 <hgoel> might be cool to make the sign also affect shift direction, but that'd be kinda pointless
12:34:06 <aalm> truncate
12:34:13 <hgoel> haven't decided if my chars are going to be utf-8 or 16
12:34:25 <hgoel> but, it'd be ub
12:35:15 <zid> truncate is super easy on x86 ;)
12:35:26 <hgoel> that's true
12:37:08 <hgoel> but it's not really intended use of char like that either
12:37:19 <zid> it is in C
12:37:20 <aalm> 4321 ftw.
12:37:34 <zid> int truncating to char is *very* important
12:37:48 <hgoel> ah in that sense
12:37:53 <zid> good luck writing %c in printf without it :P
12:38:11 <hgoel> mandatory type casting
12:38:31 <zid> in C there isn't actually a cast, due to how varargs is implemented
12:38:31 <hgoel> as C# does it
12:38:52 <hgoel> casting down requires explicit casts, casting up can be implicit
12:38:55 <zid> on either side, as int to char doesn't need one without -Wconversion
12:39:08 <zid> yea I don't mind making downcasting implicit
12:40:06 <hgoel> I've had annoying bugs from code written while half asleep relating to implicit downcasting before lol
12:40:23 <zid> implicit upconversion has bitten me more often
12:40:29 <zid> a<<1 etc
12:40:34 <zid> the 1 is an integer so a is promoted, etc
12:41:17 <zid> like, int c = b<<8 | a<<1; or whatever can go.. horrifically wrong if you're not careful with types :P
12:41:53 <hgoel> ah, that hasn't really been too problematic for me
12:42:04 <zid> I had it happen once or twice
12:42:10 <zid> that a bug was due to something like hat
12:42:23 <zid> so my RGB had the top bit of the G in the low bit of the R or whatever
12:42:36 <zid> because it was suppsoed to roll off but didn't
12:42:47 <hgoel> the sort of bug I recall is for(uint8_t idx = 0; idx < 256; idx++){ ... }
12:43:03 <zid> gcc has warned about that for 40 years thankfully
12:43:06 <hgoel> yeah, I'm used to having masks just to be sure
12:43:21 <zid> my favourite OSdev bug is not being able to enumerate the full range of something easily
12:43:27 <zid> because it's hard to write a valid terminating condition
12:43:36 <hgoel> yep
12:45:24 <hgoel> osdev tends to have the most interesting bugs in general lol
12:45:45 <hgoel> a lot more room for stuff to quietly misbehave
12:46:06 <zid> oh can you make your bitfields make sense
12:46:12 <zid> rather than C who says "Implementation can do whatever"
12:46:37 <zid> so you have to do -mms-bitfields or whatever or -mno-ms-bitfields and other crap
12:47:24 <hgoel> I didn't put a ton of thought into them, just added an optional 'be' specifier to have them be big endian, little endian by default
12:51:08 <hgoel> and yeah, following gcc/clang rules, since those are the ones I'm used to
12:51:25 <zid> mingw defaults it the other way :P
12:54:56 <hgoel> haha
12:56:49 <zid> (bcause msvc des
12:57:00 <zid> hi keyboard, nice of you to work so well
01:13:07 <pterp> I'm back to i386 dev and working on ELF loading. I'm linking together a static libc library and the programs main object file. When it jumps to strlen, it finds zeroed memory, even though I do load enough data that it should not be zeroed. Code:https://pastebin.com/yy7bFbrr
01:18:56 <bauen1> pterp: the output of the various klog calls would be interesting aswell (and maybe the output of readelf (irrc) to compare it to)
01:19:12 <bauen1> and the point where it tries to jump to too
01:20:26 <pterp> Klog calls: https://imagebin.ca/v/4fb2Y79sLAn1, Jump to main or strlen?
01:20:41 <bauen1> also is that all that is really needed to load an ELF executable ? I should have implemented this long ago
01:20:54 <bauen1> pterp: the value of header.entry
01:21:12 <zid> https://github.com/zid/boros/blob/master/boot/main.c#L227 That's my elf loader, bauen1
01:21:42 <bauen1> why haven't i written one yet, that would have saved me a lot of magic numbers ._.
01:22:00 <pterp> Entry: 0x8048074
01:22:24 <bauen1> could you do `objdump -xards` on the ELF ?
01:22:57 <bauen1> assuming that fread actually loaded the memory at that position, everything _should_ be ok
01:24:06 <pterp> ok. https://pastebin.com/i5Y0xbkm
01:28:32 <bauen1> but before the jump into the programm, the memory at 0x8048074 is zeroed ?
01:30:43 <pterp> Yes. This line is run on section load after allocating the memory at the right vaddr: memset((void*)pheader.vaddr,0,pheader.memsz);
01:31:08 <bauen1> i mean when it tries to jump into _start
01:31:14 <zid> I thought you *problem* was that it was zero'd
01:31:29 <zid> r*
01:32:15 <pterp> That's in the elf spec. But no. The main function(_start) is fine, but strlen is completely zeroed
01:32:21 <bauen1> oh
01:35:20 <bauen1> pterp: are you sure that fread actually reads what it's supposed to be ?
01:35:53 <bauen1> memset or fread not reading enough would be the only possible cause (as far as i can see, and assuming that alloc_memory_virt does it's job)
01:36:05 <pterp> I think so. Mybe the initrd drivers broken. I'll try getting the first byte of strlen manually in gdb and see if it works.
01:36:09 <bauen1> memset should work correctly too
01:36:49 <bauen1> meanwhile i'm battleing with building gcc
01:37:03 <bauen1> the configure says, that AS_FOR_TARGET is important, but configure just discards it ._.
01:39:38 <pterp> It works when i manually read it.
01:39:47 <zid> check your mapping
01:40:04 <zid> bochs has 'page' if you have bochs available
01:40:56 <pterp> ok. That first section IS one page though, so the mapping isn't it. (The second section isn't from a file)
01:41:03 <bauen1> ^
01:41:13 <bauen1> does alloc_virt_memory set it to 0 ?
01:41:20 <bauen1> if so, memset to something like 0xAA
01:41:30 <pterp> ok.
01:41:42 <bauen1> change the memset to use 0xAA in the loader
01:41:55 <zid> bauen1: I did that once for testing, then completely forgot I'd done it and spent 20 minutes trying to figure out why one of my pointers was AAAAAAAA :p
01:41:57 <pterp> BTW, it doesn't zero it, just maps it.
01:42:00 <bauen1> i highly doubt that memset is overriding it, but that's an easy way to find out
01:42:01 <bauen1> lol
01:43:05 <pterp> fread is NOT loading it properly.
01:44:04 <zid> This absolutely isn't how regular idiots like me load ELF files btw
01:44:13 <zid> you just load the entire file into memory, then map it to the right place
01:44:22 <zid> rather than dicking around reading it piece by piece
02:12:46 <pterp> IT was sign extension in my initrd driver. The 0xFF was geting extended to -1 when I didnt want it to be, Fixed that andc IT WORKS!! ELF loading works!! Time to make it a true microkernel.
02:13:05 <klange> \o/
02:13:09 <pterp> ?
02:14:06 <_mjg> he is happy for you
02:14:14 <pterp> Ah.
02:14:15 <klange> It's a pictographic representation of a person with their arms in the air in an expression of joy.
02:14:15 <_mjg> i happen to be indifferent
02:17:18 <_mjg> fun fact, untarring freebsd on to tmpfs with skylake takes half the time needed by westmere (2010-ish)
02:27:26 <bauen1> fun fact: building gcc takes forever, and it just failed again
02:27:58 <bauen1> oh amazing i might be an idiot
02:28:13 <klange> tell me about it
02:29:59 <bauen1> so first of all i can't figure out how to pass a modified PATH to recursive calls of make for only a few select targets
02:30:18 <bauen1> second i didn't proof read my code before kicking off a 45 minute build of gcc
02:35:00 <bauen1> amazaing, i just can't figure out how to build gcc
02:36:26 <_mjg> try building llvm
02:36:27 <bauen1> guess we'll find out if i'm stupid in approximately 45 minutes
02:36:48 <_mjg> people retire before it finishes
02:37:04 <_mjg> ultimate corporate stalling tool
02:38:35 <klange> Try building Qt5...
02:38:35 <bauen1> hm, does the target assembler already have to be in the PATH when running configure ?
02:38:48 <bauen1> i tried building webkit on this laptop once
02:38:57 <bauen1> gave up after irrc 5 hours
02:39:14 <bauen1> actually, that was in a 2 core vm
02:39:24 <_mjg> oh no
02:39:29 <_mjg> just no
02:39:32 <bauen1> yes
02:39:47 <bauen1> i'm never doing linux from scratch on a laptop every again
02:39:51 <_mjg> say no to compiling on your laptop
02:40:12 <bauen1> actually, distcc should be plug and play now that my toolchain build script is a makefile itself
02:40:25 <bauen1> but distcc has some problems with building gcc
02:40:44 <bauen1> actually
02:40:54 <bauen1> let me spin up a 20 core vm and run it
02:46:26 <bauen1> alright i'm stupid, of course build takes forever if you use -j 1
02:47:37 <_mjg> unless it fails first!
02:48:14 <bauen1> ._.
03:02:02 <bauen1> YES
03:02:03 <bauen1> IT WORKS
03:16:41 <bauen1> i now have a 150 line makefile monstrosity that will build me any toolchain i need :)
04:00:41 <gog> pickup lines for programming geeks: check out my github and send me a pull request (kissy face emoji)
04:04:43 <zid> die
04:06:14 <gog> kill -9 gog
04:06:19 <gog> killall
04:55:50 <bauen1> klange: so i'm looking a bit over your makefile and your using `.SECONDARY:` to stop make from removing intermmediate files, even if the rules fail, doesn't that break the build if you interrupt make/the command and the file has been partially written ?
06:30:03 <geist> bauen1: hmm, i've never used .SECONDARY
06:30:15 <geist> it's not a requirement, are you thinking of using it for something?
06:32:23 <bauen1> no i'm just wondering if klange every thought about the effects it has (apart from saving compile time)
06:34:01 <bauen1> actually the manual only says for .PRECIOUS that the files won't be deleted if make is interrupted, about .SECONDARY it only says, they will never be deleted
06:38:29 <geist> klange is smart, it's probably for a reason
06:43:30 <Brnocrist> .theo
06:43:30 <glenda> That's a load of bull.
06:49:25 <geist> aww theo why cant we all just get along?
06:58:04 <bauen1> programmers are the most volatile thing of any program
06:59:02 <geist> i think you identified the problem!
07:00:33 <_mjg> programming sucks. i'm switching to management.
07:02:13 <bauen1> hm, is it a stupid idea to have an order-only dependency on $(CC) (after it has been resolved to an absolute path) to trigger the building of the toolchain when needed ?
07:03:01 <aalm> hah
07:03:18 <geist> you could. i'd do it more specifically by having everything of a particular type of source depend on a phony rule like 'toolchain' or whatnot
07:03:24 <geist> that way you could also do make toolchain
07:03:35 <aalm> management has it's own problems
07:03:36 <bauen1> i already have a rule to build the entire toolchain
07:03:40 <aalm> .theo
07:03:40 <glenda> Too bad. You can use other software.
07:04:08 <aalm> bauen1, how's the kernel lines increasing?
07:04:11 <bauen1> uhm
07:04:27 <geist> so in that case it may be simpler to just have say all .c files depend on 'toolchain'
07:04:41 <geist> since the toolchain is more than just CC
07:04:45 <zid> yea I have a utils/ dir in a similar matter
07:04:47 <geist> (or whatever $(CC) points at)
07:04:52 <bauen1> holding at a steady 1kloc
07:04:55 <zid> that dir has to be built and the .o files depend on it
07:05:28 <bauen1> CC depends on a target that is all that should be needed (libc will be build later and you need an extra dependency on it anway)
07:05:41 <bauen1> guess i'm not entirely crazy after all
07:06:05 <bauen1> i do have a nice ~400 lines of make now
07:06:26 <aalm> does it make it
07:06:43 <zid> all: *.c\n\t gcc *.c
07:06:45 <zid> that's my makefile
07:07:02 <bauen1> zid: does your makefile support building a toolchain and parallelism ?
07:07:07 <zid> yep
07:07:10 <bauen1> ._.
07:07:37 <bauen1> so i've waste ~10 hours on 400 lines of make when 2 would have been enough
07:07:54 <geist> no the wildcard stuff id ont recommend for large projects
07:08:14 <bcos> Next step is to write a compiler, to compile the makefile into fast native machine code
07:08:16 <geist> it's useful for small things, but wildcarding has lots of issues. if anything it doesn't handle subdirs
07:08:25 <geist> and stale .c files get compiled, etc etc
07:08:27 <zid> bcos: Don't forget to implement Make
07:08:38 <zid> geist: sorry did I say * I meant find . -name *.c
07:08:53 <geist> fine, but still. it's a useful shortcut but i wouldn't recommend it for larger projects
07:09:08 <zid> I just have a source dir, if you're in it you're built and linked
07:09:13 <zid> too early for kconfig etc
07:09:24 <geist> exactly
07:09:34 <geist> a pile of files that always compile with the same switches? great.
07:09:43 <geist> useful for simple apps and whatnot
07:09:51 <aalm> simply great
07:10:02 <zid> and my 'other' stuff are dependancies, and recursive make cus whatever
07:10:59 <bauen1> ewww recursive make
07:11:03 <doug16k> non-recursive make runs very much faster and more parallel than recursive in my experience
07:11:11 <bauen1> yes
07:11:24 <zid> but then you've essentially written two makefiles into one makefile, which is also kinda meh
07:11:26 <zid> it's meh either way
07:11:32 <zid> but one is easier
07:11:34 <bauen1> and if you're doing make recursively atleast add + infront of $(MAKE)
07:11:43 <bauen1> to allow some parallelism
07:21:38 <geist> sure. i'm not judging, i just know that the more complex but ultimately 'best' solution is generally a single non recursive make
07:21:55 <geist> but there are various levels of 'i just want this to work' that you can do that usually sacrifice somethign in the name of expediancey
07:22:18 <geist> and usually the real benefits of a non recursive make only kick in once the project is large enough, and/or requires some amount of dynamic configurability
07:23:14 <bauen1> true
07:24:14 <geist> at the end of the day do what works for ya
07:24:47 <geist> it personally gives me a good feeling to put together a solid build system, even if it's overengineered for smaller stuff, but it's more of a case of once you've done a 'big' one it's fairly easy to blat out a simpler one
07:25:13 <geist> something like https://github.com/travisg/3x86/blob/master/makefile is what i'd recommend for a simpler project
07:25:40 <geist> still uses %:% rules and does propr deps and whatnot and is a bit configurable, but isn't heirarchial
07:26:55 <catern> here is an osdev meme based on my lived experience https://imgflip.com/i/2zwysg
07:27:46 <bauen1> lol
07:28:15 <bauen1> having messed up linked lists quite often when doing task switching, i can relate to that too much
07:28:28 <zid> The last one is all my in development code
07:28:34 <zid> which shortly becomes production code
07:28:40 <zid> with a sticky note saying to not have more than 4 pci devices
07:32:59 <bauen1> i'll do another test build and tomorrow i'll commit this beast of a build system so you can judge it
07:47:06 <doug16k> gnu libc docs say this: "If a program stores integer data in a location which is then used in a floating-point operation, this often causes an “invalid operation” exception, because the processor cannot recognize the data as a floating-point number."
07:47:31 <doug16k> nonsense. every bit pattern is a valid floating point number
07:47:48 <bcos> sNaN
07:47:56 <doug16k> ok. still valid
07:48:22 <doug16k> cannot recognize snan as a floating point number?
07:48:29 <bcos> None of the "not a number" things are a number
07:49:03 <bcos> (but I think only sNan would give invalid operation on 80x86)
07:50:30 <doug16k> I understand, I am a little annoyed by how misleading it is and how it just reinforces fear of floating point
07:50:54 <bcos> The "often causes" is wrong - should be "may cause"
07:51:30 <doug16k> mysterious mean invalid values will jump you and you will die when they strike
08:17:23 <geist> i suppose it could be that on some arches that aren't IEEE floating compatible that may actually be the case
08:18:29 <geist> or maybe it's saying somethign to the effect of 'what you load in this may be a NaN or a denormalized float, which may trigger an exception on some architectures upon using it'
08:18:47 <geist> i know certainly on some fpus you can get it to trigger an exception on a denormalized number, at least
10:37:54 <stisl> hi
10:38:49 <stisl> Where can I find a documentation about the UEFI Function from RuntimeServices called ConvertPointer
10:39:39 <stisl> It looks like that it is not so unimportant for booting an operating system properly
10:40:26 <stisl> the question is more what the first parameter is doing
10:41:23 <stisl> in the example codes I found it is mostly zero, but what does zero mean?
11:26:37 <mischief> stisl: it's in the UEFI specification.
11:26:55 <mischief> (along with everything else UEFI)
11:27:20 <stisl> thx mischief
11:28:04 <stisl> now everything is clearre
11:28:30 <stisl> it is important to do this they describe when you are doing virtual address mappings
11:31:36 <stisl> mischief, why is there only one valid value for the first parameter? (0x1)
11:33:02 <mischief> no idea, i haven't messed around with UEFI in a long time. i don't think it is required to boot an os.
11:33:18 <mischief> maybe the #edk2 channel on the OFTC network can help.
11:33:44 <stisl> ah, thx
11:34:51 <stisl> for my new computers it is unfortunately important :( because with the legacy bios emulation I get a lot of more trouble