<doug16k>
I wonder if I objcopy delete the debug like that first, then from that do pe-to-pe that deletes 1st one
isaacwoods has quit [Quit: WeeChat 3.1]
bsdbandit01 has joined #osdev
gog has quit [Ping timeout: 272 seconds]
bsdbandit01 has quit [Read error: Connection reset by peer]
GreaseMonkey has joined #osdev
lleo has quit [Ping timeout: 264 seconds]
pretty_dumm_guy has quit [Quit: WeeChat 3.2-rc1]
orthoplex64 has quit [Ping timeout: 272 seconds]
elastic_dog has quit [Ping timeout: 268 seconds]
elastic_dog has joined #osdev
<doug16k>
gcc 11 is breaking everyone's Werror
<maurer>
What fun new errors did they add?
<maurer>
err, fun new warnings rather
<doug16k>
vla-parameter brotli/c/dec/decode.c:2034:14: error: argument 4 of type ‘uint8_t *’ {aka ‘unsigned char *’} declared as a pointer [-Werror=vla-parameter]
<doug16k>
ovmf won't build
<doug16k>
I am going to finally see what their pe loader really does
<doug16k>
nothing good, apparently
<doug16k>
my efi executable that looks valid now, ends up executing zeros at rip=0x20, before it hits entry point
<doug16k>
I let ld corrupt the headers of a sacrificial first section then removed it with objcopy, after removing debug info
<maurer>
so, the vla-parameter thing basically means that in one signature they did `uint8_t*`, and in the other they did `uint8_t [n]` for some n.
<doug16k>
they both decay to a pointer
<doug16k>
it's C
<doug16k>
I mean, that's why it was okay before
<maurer>
Sure, but the C compiler is allowed to make assumptions about the minimum number of elements in one of them
<doug16k>
I don't think it is
<doug16k>
sure about that? it's just ignorance to put an array as a parameter
<doug16k>
in C
<doug16k>
because we know it is really a pointer, it can't pass an array
<doug16k>
I should screw around with it though, to see what you can get that to do
<maurer>
The value that gets passed is a pointer, but the compiler is allowed to *assume* things about that pointer
<doug16k>
what difference would it make
<doug16k>
you mean C is afraid to overrun arrays? I hadn't noticed
<doug16k>
it seemed like it loved to
<maurer>
No, but it can be used as information for the strict aliasing rule
<moon-child>
void *hereby = NULL; //hereby declared NULL and void
<moon-child>
*
flx has joined #osdev
chartreuse has joined #osdev
iorem has quit [Quit: Connection closed]
ZombieChicken has joined #osdev
skipwich has joined #osdev
mctpyt has quit [Ping timeout: 244 seconds]
mctpyt has joined #osdev
chin123 has quit [Remote host closed the connection]
chin123 has joined #osdev
<moon-child>
thoughts on absolute vs relative timers?
<moon-child>
have to keep track of partial deltas, or annoyances when the clock changes. Leaning towards absolute, because clocks changing isn't a happy path, so you can deal with it however annoyingly when it comes
GeDaMo has joined #osdev
Sos has joined #osdev
iorem has joined #osdev
aerona has quit [Quit: Leaving]
<doug16k>
absolute is way better
<doug16k>
then you think in ideals instead of chasing skids
<doug16k>
if you compute a relative time, then use it, how were you sure how much time elapsed between computing it and using it? the longer that is, the more wrong it is. with absolute, it doesn't have error added
<doug16k>
it's bad in vms too. you get strange time warps where time jumped forward a good bit
<doug16k>
you starved for cpu for a moment or something
<doug16k>
you can pause and resume vms too, to cause massive time warps
tenshi has joined #osdev
<kingoffrance>
almost sounds like ntp
<kingoffrance>
should you disallow giant leaps? slowly drift so its not as disturbing?
<doug16k>
you can tell qemu how to do it
<kingoffrance>
*slowly fix towards correctness in tiny steps
<doug16k>
it can be tell me the truth, or interpolate
<doug16k>
if you are using something like virtualized apic, it is hard to not see the truth
<doug16k>
you see the real timer
<doug16k>
I think you can adjust a ratio though, to interpolate that
<doug16k>
warp is best
<doug16k>
if you can tolerate it
<doug16k>
it's pretty weird when it is "catching up" and cursor is flashing like crazy and time is flying in the guest
<doug16k>
in the guest frame of reference, suddenly the cpu is very slow
<doug16k>
getting very little work done for a lot of time elapsing
<doug16k>
that will screw you up more than time jumping once
<doug16k>
spending an excessive amount of time in context switch because it seems like threads are running really long
<doug16k>
but in reality you are thrashing because not much time is elapsing
<klange>
Heh, I can boot to GUI on my Surface, but there's no PS/2 emulation so I just get a big useless desktop - but the clock is ticking nicely!
<doug16k>
what's the interface to touch? usb?
<doug16k>
or uglier like i2c?
<klange>
It's... not fun.
<klange>
ME actually handles receiving the sensor data, so no clue on the actual hardware interface.
<doug16k>
oh no
<klange>
And you get very raw data handed to you by ME, which Linux passes off to a userspace daemon, because actually processing that data is so annoying and intensive _it gets the GPU to do it_.
<doug16k>
almost seems non-accidental
<doug16k>
microsoft went through a phase where they were trying to make machines locked down to only boot windows
<klange>
I think I'll just get a USB stack and plug in a real mouse. The keyboard here is also wacky usb over i2c thing...
<doug16k>
oh, reminds me of rpi a bit
<doug16k>
is it a generic standard usb host controller?
<doug16k>
xhci?
<doug16k>
I am guessing they use the one in the cpu SoC
<klange>
I need to boot back into Ubuntu to get some better hardware details, but I believe so.
<doug16k>
that's good
<klange>
Just pushing two little patches that got me to the gui first, had to actually give up on ps/2 and also wasn't mapping enough video memory for the humongous framebuffer I was getting from grub-efi
<klange>
(since of course it happily gave me all of the glorious pixels)
<klange>
Thanks to prior work done in virtualbox, I generally have no trouble with big screen resolutions, but I did hardcode a size to map while hacking up the current iteration of the generic driver...
asymptotically has joined #osdev
gareppa has joined #osdev
gareppa has quit [Quit: Leaving]
doug16k has quit [Remote host closed the connection]
doug16k has joined #osdev
ZombieChicken has quit [Quit: WeeChat 3.1]
sortie has joined #osdev
dutch has quit [Quit: WeeChat 3.1]
<doug16k>
what is this qemu output: Invalid access at addr 0xFFFFF80065B1D, size 1, region '(null)', reason: rejected
<doug16k>
ah... debugger trying to insert breakpoints
<doug16k>
before it even ran bios
<sortie>
Oh hello doug16k
<sortie>
You still up and dealing with cursed things?
<doug16k>
yes
<klange>
why am I thinking about boot things right now... so disorganized
<klange>
my bios loader stopped working again, looks like it's trashing stuff when loading the kernel and then failing to load the ramdisk; tsk
<klange>
Two days gone and I continue to not actually work on the netstack, typical.
<doug16k>
gdb compare-sections is great for troubleshooting imperfect load
<doug16k>
tells you which sections don't match the executable right now
<doug16k>
usually you need -r to do only readonly, but at kernel entry you can do it all
<klange>
what's the magic bios api for getting the bootdrive, passed by some register when it hands control to you?
<doug16k>
dl register
<doug16k>
if bit 7 is 0, then put 0x80 in dl
<doug16k>
dl is the drive number
PotatoGim has joined #osdev
<klange>
I think I can just reorder some things, shove the disk loads up into the real mode bootstrap as bios reads, and keep the fancy protected mode menu, maybe even fix it up with a line editor
<klange>
I don't want to set up a trampoline to jump back and forth, and unlike toaru32 I no longer have to manage a list of blobs to load, there's two things, and I load both of them.
<klange>
Actually _using_ multiboot modules for "modules" was a mistake.
<klange>
One module for a ramdisk is fine, but the mess of having kernel drivers in them - and with ordering requirements for dependencies - was not worth the pain.
<klange>
Plus it got me complacent with having modules loaded and 'running' during early startup, so several were weirdly broken if you tried to load them by the system call.
<klange>
Thinking do the memory check, verify at least a reasonable space above 1MB, load the kernel and ramdisk somewhere sufficiently higher than where I would expect the kernel to end, then I can jump to the 32-bit C main and show the check boxes with everything all ready to go.
<klange>
Then I just do some Elf32 phdr loading, move the ramdisk up a bit so it's nice and flush, spit out the multiboot struct, and away we go. Kernel does the long mode jump, decompresses the ramdisk on its own, ramdisk will eventually have driver modules again.
<klange>
Question I still have for myself is whether I should fix up the EFI loader to not jump back to protected mode... I still want it to load the same 32-bit ELF kernel image, and it's not too hard to set all the right flags and stuff to get back to protected mode to let the kernel bootstrap itself back into long mode...
<klange>
But then I'm also thinking what if I did an EFI stub...
piotr_ has joined #osdev
<sortie>
Yo klange
<klange>
Yo sortie
<sortie>
Sounds like you're doing some good ol' osdev :)
<klange>
Just want to not be shipping a grub rescue CD for this 2.0 release :)
<sortie>
I'm uh (checks notes) writing a sort(1)
<klange>
I have heard, very appropriate.
<klange>
Imagine a sortix with no sort!
<sortie>
I still need to decide on a -x option
<sortie>
klange, it's actually, uh, the one thing between me and being fully self-hosting. I need sort -k for that. It all boils down to a sort. (Although I still need to package up my perl and texinfo ports)
<sortie>
What's next for your netstack?
<klange>
drawing the rest of the ***ing owl
<klange>
nah, sitting down and writing a proper TCP implementation with actual timeouts and reordering
<klange>
the general socket API here seems... reasonable, if convoluted and poorly implemented, but those should be resolved eventually when if I ever have some time and patience to write better threading and collection primitives
<sortie>
lol at the owl meme
<sortie>
Sounds good :) I know the feeling, loooots of netstack polish is needed
<sortie>
I still haven't merged or finished my circa 2015 netstack
<sortie>
But! I've come up with an actual plan for finishing all my WIP stuff instead of doing more and even more WIP stuff forever
<sortie>
I'm so embarrassed when people want to try out my stuff and I have to point them to a volatile stinking pile of WIP
<GeDaMo>
'some assembly required' :P
<sortie>
:D
<GeDaMo>
'... and if you get it working, can I get a copy?' :P
gareppa has joined #osdev
gareppa has quit [Remote host closed the connection]