<heat>
geist, how do I build lk with the do-qemu$arch scripts for a a different subarch?
<geist>
for a new subarch?
<geist>
usually they just buid the project and run it
<heat>
no
<heat>
i wanna build it for x86_64
<geist>
use help, there's a switch for that
<heat>
./scripts/do-qemux86 builds it for x86
<geist>
i believe -6
<geist>
--help shows you the usage
<heat>
oh I see!
<geist>
same with arm. -6 does 64bit, -3 does cortex-m3
<geist>
and same weith riscv
<heat>
is it possible to directly set the cross compile prefix?
<geist>
yah see TOOLCHAIN_PREFIX
<heat>
does it even work btw?
<geist>
and there's spcific ones for TOOLCHAIN_PREFIX_x86_64, etc
<geist>
well sure
<heat>
like compiling it with a non-bare-metal compiler that assumes pie and whatnot
<geist>
well that may not work, but the build system generally overrides everything
<geist>
-ffresstanding, etc
<geist>
note if you have customizations to the build syste you want to stick, you can create a file called local.mk that just sets defaults and whatnot
<geist>
it's always sourced by the build system
<geist>
i use it locally to set default projects and whatot with `PROJECT ?= my-default-project`
<geist>
the ?= means it can still be overridden by the command line
<geist>
or environment
<geist>
the local.mk is where you can set a bunch of TOOLCHAIN_PREFIXes for the different arches
<geist>
i use it when testing a new freshly built compiler and whatnot that i haven't added to my path yet
<heat>
huh, doesn't work
<heat>
i'll grab one of your toolchains I guess
<geist>
lets take it to #lk
<bauen1>
geist: -fcallgraph-info=su does almost all the work for determing worst case stack usage, execpt it doesn't tell you if a symbol is weak/global/local (i think), you need to do the "linking" yourself and it doesn't work with lto
<geist>
makes sense
<bauen1>
hm, actually it does output the local labels with the source prefixed, so maybe it does differentiate between them enough that i won't have to use readelf, not sure about weak symbols yet
<bauen1>
and i'm also just assuming lto wouldn't increase stack size, that should work out usally right ?
Guest3459 has quit [Killed (calcium.libera.chat (Nickname regained by services))]
vinleod is now known as vdamewood
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 256 seconds]
ZipCPU_ has joined #osdev
ZipCPU has quit [Ping timeout: 256 seconds]
ZipCPU_ is now known as ZipCPU
moon-child has quit [Quit: !]
moon-child has joined #osdev
ids1024 has quit [Ping timeout: 260 seconds]
ids1024 has joined #osdev
gildasio has joined #osdev
enkeyz has joined #osdev
nur has joined #osdev
GeDaMo has joined #osdev
Likorn has joined #osdev
dh` has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
Burgundy has joined #osdev
ZipCPU has quit [Ping timeout: 240 seconds]
ZipCPU has joined #osdev
gxt has quit [Ping timeout: 240 seconds]
gxt has joined #osdev
ZipCPU has quit [Ping timeout: 256 seconds]
ZipCPU has joined #osdev
corank_ has quit [Remote host closed the connection]
Brnocrist has quit [Ping timeout: 248 seconds]
corank_ has joined #osdev
Brnocrist has joined #osdev
bauen1 has joined #osdev
mavhq has quit [Ping timeout: 256 seconds]
bauen1 has quit [Ping timeout: 246 seconds]
bauen1 has joined #osdev
gog has joined #osdev
corank_ has quit [Remote host closed the connection]
corank_ has joined #osdev
Jmabsd has joined #osdev
<Jmabsd>
I'll ask an ARM architecture question here as you may know the answer: Great to be on this channel. Re an ARM system's "IPA size", do I get it right that it will *not* affect OS, OS process' virtual memory, a VM's maximal size or the virtual memory a VM guest's OS or OS processes have?
<mjg>
if i read it right ipa is just the physical memory
<mjg>
so no
<mjg>
supporting only a small range of physical memory vs a drastically bigger virtual memory is pretty standard
mavhq has joined #osdev
corank_ has quit [Remote host closed the connection]
corank_ has joined #osdev
<nomagno>
Why don't operating systems zero-initialize memory spaces for processes?
<nomagno>
Is it that costly?
<nomagno>
its just memset zero
<Jmabsd>
nomagno: OpenBSD does i'm sure
<Jmabsd>
with like 0x1234678 lol
<GeDaMo>
I seem to remember a discussion on ere a while back about per-zeroing pages
<GeDaMo>
s/ere/here/
<GeDaMo>
s/per-/pre-/
corank_ has quit [Remote host closed the connection]
<GeDaMo>
Maybe even a process which zeroed pages
corank_ has joined #osdev
<nomagno>
It's probably the least complex safety-increasing measure
<nomagno>
In any OS written in C you just do memspace = {0}, boom done
<nomagno>
Or memset
<GeDaMo>
It still takes time to do
<GeDaMo>
Any page that you hold as pre-zeroed is a page you can't use for running programs or as a disk buffer
nj0rd has joined #osdev
enkeyz has quit [Quit: =^.^=]
diamondbond has joined #osdev
diamondbond has quit [Quit: Leaving]
diamondbond has joined #osdev
<mrvn>
nomagno: I'm pretty sure all serious OSes initialize memory for processes.Problem is memory reusage.
<mrvn>
nomagno: memspace = {0} is code that works but not correct code. Padding bytes may not be initialized to 0.
diamondbond has quit [Quit: Leaving]
<nomagno>
mrvn: I write a bad VM, not a bare-metal OS ;)
<mrvn>
GeDaMo: why wouldn't you use a pre-zeroed page for programs or disk buffers? It would be wastefull in most cases but no reason not to use them in a pinch.
<nomagno>
Tough I'm definitely setting my sights on a hobby OS so I can have the same godlike aura some of the people on here do!
<mrvn>
nomagno: even more important to get it right. Always write correct code when you can, make it a habbit.
<nomagno>
mrvn: The padding bits on this struct aren't accessed
<nomagno>
So the code is correct as far as my codebase is concerned
<nomagno>
The memory is not the struct itself, but arrays that are members of the struct
<mrvn>
nomagno: says who? The malicious attacker that wants to steal your hosts ssl keys certains will read them.
<mrvn>
nomagno: your code is working, it isn't correct. Correct has a much stricter requirement that excludes relying on how your compiler happens to do things.
<nomagno>
mrvn: if I say it's correct, I mean it. I am zeroing out the members of the struct, not the struct. I agree the code is incorrect for the context I originally brought it up in
<mrvn>
nomagno: that might be true.
<mrvn>
On that node: What does memspace = {0} do with a uinion? Just zero out the fireld of the first choice, right?
<mrvn>
s/fireld/fields/
SR-71 has quit [Ping timeout: 250 seconds]
<mrvn>
from the ARM ARM: "In practice, it is unlikely that software will use ASIDs differently across processors." Who does that?
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
srjek has joined #osdev
bliminse has quit [Quit: leaving]
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
Teukka has quit [Read error: Connection reset by peer]
Teukka has joined #osdev
bliminse has joined #osdev
enkeyz has joined #osdev
<vin>
I see a weird performance behavior that I am not able to explain. I am doing random reads at an offset of a file and loading it to a buffer at a predefined offset. Now since these random reads are independent I made them async. I come to know the file offset I should be reading one loop at a time, so I submit this read to a future vector. Once the buffer is full, I wait until all reads have finished
<vin>
by doing a get on future and write.
<vin>
However! Since I am doing multiple random reads at once, I expected a huge bandwidth utilization on the device but there is close to none
panosdev has quit [Quit: WeeChat 3.5]
corank_ has quit [Remote host closed the connection]
corank_ has joined #osdev
rorx has quit [Ping timeout: 246 seconds]
lg has quit [Ping timeout: 272 seconds]
<geist>
GeDaMo: re: zeroing pages
<geist>
all serious OSes provide zeroed pages, the question was whether or not the OS continually zeroes pages in the background that are not in use
<geist>
so that pages are already zeroed at the time they're allocated
<GeDaMo>
Yeah
<geist>
vs on demand zeroing
gog has quit [Ping timeout: 256 seconds]
Likorn has joined #osdev
haliucinas has joined #osdev
mahmutov has joined #osdev
lg has joined #osdev
rorx has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
Dreg has quit [Read error: Connection reset by peer]
Dreg has joined #osdev
<clever>
geist: ive seen at least 2 pieces of evidence of gpu ram not being pre-zeros
<clever>
1: after a reboot from win7 to linux, and after logging into my display manager, it briefly showed a corrupted copy of the windows wallpaper!!
<clever>
2: mineacraft sometimes generates a texture atlas and saves it to disk, the unused corners contain corrupted copies of applications i commonly run
<papaya>
That seems kinda weird
<clever>
papaya: yeah, the windows wallpaper is clearly a major violation, its using un-initialized data
<clever>
tooltips also do that a lot on this gpu driver, the 1st time they render, its garbage
<clever>
and the 2nd time it renders, its fine
<papaya>
but I guess the location of gpu memory used for that screenbuffer is fixed so when the screen res changed that data was there?
<clever>
yeah
<clever>
and there is just a touch of bitrot from the refresh being off over reset
<papaya>
but wouldn't it have like the Windows shutdown screen then isntead of the desktop wallpaper
<clever>
whats weirder, is that the gpu was already doing graphics before that
<clever>
as-in, my login screen is graphical
<clever>
and only after i login, and xfce starts up, do i see the windows wallpaper
<clever>
it might not be the final 2d framebuffer, but the 3d texture ram
<clever>
and after i login, the compositing window manager takes over, and starts using uninitialized textures
<papaya>
and I'm guessing the login screen res is identical to the desktop res
<bslsk05>
github.com: linux/v3d_mmu.c at rpi-5.10.y · raspberrypi/linux · GitHub
<clever>
on bcm2711 v3d, there is a dedicated mmu, so you can just not map kernel .text to the 3d core
lg has joined #osdev
<clever>
but its not restricting what addresses the shaders touch
<clever>
so you can trample over 3d state for any other program on the system
<heat>
exactly lol
<clever>
on vc4, there was no mmu, so you could trample on ANYTHING in ram
<clever>
and thats why the driver audits things, and stops you
ThinkT510 has joined #osdev
freakazoid333 has joined #osdev
dude12312414 has joined #osdev
<mrvn>
lol, bonus reward for Matt Parkers Humble Pi show on kickstarter: "I will spell your name slightly wrong. £3About €4. You heard me. I will make a semi-trivial spelling mistake or glitch in your name (except on any postal address labels). Please note that these accumulate. If you choose more than three errors your name will start to be unrecognisable. You'll know what it is (because I'll email it to you),
<mrvn>
but no one else might."
<clever>
lol
vimal has quit [Quit: Leaving]
lg has quit [Ping timeout: 272 seconds]
bauen1 has quit [Ping timeout: 240 seconds]
<mrvn>
clever: can you make the GPU write to the UART?
mahmutov has quit [Ping timeout: 248 seconds]
<mrvn>
.oO("take texture, run neural net to detect text, output to UART"-shader :)
<clever>
lol
<clever>
its plausible that it could control the i2c port on the hdmi port
<mrvn>
if it can write to any address you just have to find a way to circumvent the drive detecting it
<clever>
ah, you mean the host uart
<clever>
dma might be able to do that
<mrvn>
peripherals are just addresses
<clever>
yeah
<mrvn>
you just have to make a 1x1 RGBA texture located at the UART0 DR and get that past the driver.
<mrvn>
and then go really slow to not exceed 115200 BAUD.
bauen1 has joined #osdev
<clever>
at least on the rpi, its not possible to make a 1x1 texture