klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
orthoplex64 has quit [Remote host closed the connection]
orthoplex64 has joined #osdev
<kazinsal> well there's a terrifying phrase I just read. "swapfile via nfs over wifi"
<mjg> i have something worse mon
<bslsk05> ​twitter: <tjhorner> wait you can actually download more ram if you set up google drive as swap space
<kazinsal> oh no
<mjg> sweet dreams
<mjg> just ran into a tune i have not heard in years https://www.youtube.com/watch?v=7pfRAlr-k2c
<bslsk05> ​'All The Angels' by Dead Confederate - Topic (00:05:10)
<mjg> ... which i liked a lot but somehow forgotten about
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
kingoffrance has joined #osdev
orthoplex64 has quit [Remote host closed the connection]
orthoplex64 has joined #osdev
orthoplex64 has quit [Client Quit]
mahmutov has quit [Ping timeout: 240 seconds]
Ali_A has joined #osdev
sonny has joined #osdev
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
pretty_dumm_guy has quit [Ping timeout: 246 seconds]
nyah has quit [Ping timeout: 260 seconds]
ngc0202 has quit []
vdamewood has joined #osdev
srjek has quit [Ping timeout: 256 seconds]
<mrvn> Why does this modify %rsp? https://godbolt.org/z/4Eqx31G98
<bslsk05> ​godbolt.org: Compiler Explorer
<Ali_A> so, after booting to x86 where can I read about starting to write a VGA driver (I saw a page on VGA hardware  which is a good start but what after that?) I am using qemu so I don't have a real hardware to work with
<mrvn> Do you have a working VGA driver?
<mrvn> Do you have a working vga driver for all the vga cards qemu and bochs can emulate?
<moon-child> mrvn: stack alignment
<mrvn> ahh, because of the CALL. grrr
<moon-child> note clang has the useless pushes and pops, which accomplish the same thing
<mrvn> And why isn't it using "DIV r/m64"? Doublequadword/quadword
<Ali_A> mrvn no I just booted my kernel and I want to read about writing a VGA driver, the problem is that there are a lot of hardware `abbreviations` and things I don't know when reading online tutorials, so if there is something like `read this first` before writing a VGA driver would be great, sounds like a nooby question but honestly can not find any
<Ali_A> resources that just doesn't smash code without talking first about the hardware, how it works and so on
<moon-child> idk
<mrvn> I've added assert(a < n) but it still doesn't use div
<moon-child> replace assert with __builtin_assume?
<moon-child> (or, if(!whatever)__builtin_unreachable(), same thing)
<mrvn> Ali_A: vga and even svga is stone age tech. You don't want it anyway.
<mrvn> Urgs, gcc then adds a "call __builtin_assume"
<Ali_A> that is what I thought, but read on OSdev formus, if u never wrote a vga driver, u will be struggling to write a proper modern driver, so they suggested to start there
<mrvn> Ali_A: just tell grub to give you a framebuffer and start there
<Ali_A> I don't have that, I am boot-loading it myself
<mrvn> Ali_A: there is your first mistake
<Ali_A> '=D  which I was told countless times it is a bad idea
<Ali_A> it is my first iteration in OSdev I really wanna understand everything that happens first,
<Ali_A> it is more of understanding what the tool can do for me before I use them. at least that is my idea about it
Ali_A has quit [Quit: Connection closed]
Likorn has quit [Quit: WeeChat 3.4.1]
<mrvn> Anyone know why sqrmod doesn't produce code like sqrmod2? https://godbolt.org/z/7s3rnqasx
<bslsk05> ​godbolt.org: Compiler Explorer
<mrvn> I think the compiler is afraid of getting a #DivisionError but that can't happen for a<n.
dude12312414 has joined #osdev
<mrvn> .oO(also shouldn't the "call __umodti3" be a tail call?)
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
srjek has joined #osdev
troseman has quit [Ping timeout: 260 seconds]
knusbaum has quit [Quit: ZNC 1.8.2 - https://znc.in]
knusbaum has joined #osdev
sonny has quit [Remote host closed the connection]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
netbsduser has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
netbsduser has quit [Read error: Connection reset by peer]
bauen1 has quit [Ping timeout: 246 seconds]
rorx has quit [Ping timeout: 248 seconds]
Vercas has quit [Quit: Ping timeout (120 seconds)]
Vercas has joined #osdev
rorx has joined #osdev
GeDaMo has joined #osdev
sdomi has quit [Ping timeout: 240 seconds]
bauen1 has joined #osdev
GeDaMo has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
GeDaMo has joined #osdev
wootehfoot has joined #osdev
* Maka_Albarn has work tomorrow
Maka_Albarn has left #osdev [#osdev]
wootehfoot has quit [Read error: Connection reset by peer]
<geist> oh huh. gcc 12.1 was released
<geist> also interesting at the bottom of https://gcc.gnu.org/gcc-12/changes.html
<bslsk05> ​gcc.gnu.org: GCC 12 Release Series — Changes, New Features, and Fixes - GNU Project
<geist> it mentions CTF as a lightweight debugging format. might be a nice substitute for dwarf or whatnot for in-kernel backtraces
Vercas has quit [Ping timeout: 240 seconds]
wootehfoot has joined #osdev
mahmutov has joined #osdev
w41 has quit [Ping timeout: 276 seconds]
<kazinsal> oh, that could be handy
ex0matter has joined #osdev
<kazinsal> (Note one irregularity here: the ctf_archive_t is not a typedef to struct ctf_archive, but a different typedef, private to libctf, so that things that are not really archives can be made to appear as if they were.)
<kazinsal> oh gnu. you're so wacky.
<zid> ooh digit seps and %b
eroux has joined #osdev
Clockface has quit [Ping timeout: 246 seconds]
<zid> oh the always init stuff is now mainline eh, kernel's been using that for a loong time
eroux has quit [Ping timeout: 256 seconds]
bauen1 has quit [Ping timeout: 250 seconds]
bauen1 has joined #osdev
w41 has joined #osdev
Likorn has joined #osdev
Burgundy has joined #osdev
ex0matter has quit [Ping timeout: 240 seconds]
Vercas has joined #osdev
vimal has joined #osdev
wootehfoot has quit [Read error: Connection reset by peer]
<mrvn> goodby m68k*-*-openbsd* and vax-*-openbsd*
<moon-child> mrvn: out of curiosity, what are you using the 128-bit ints for?
<mrvn> primality test for uint64_t
the_lanetly_052 has joined #osdev
pretty_dumm_guy has joined #osdev
mahmutov has quit [Ping timeout: 276 seconds]
nyah has joined #osdev
dude12312414 has joined #osdev
heat has joined #osdev
alpha2023 has quit [Read error: Connection reset by peer]
<mrvn> You know some programming course assigned some homework when 3 people come to stackoverflow having problems writing a function "printmat".
Vercas has quit [Remote host closed the connection]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
heat has quit [Remote host closed the connection]
heat has joined #osdev
Vercas has joined #osdev
bauen1 has quit [Ping timeout: 250 seconds]
bauen1 has joined #osdev
dude12312414 has joined #osdev
ngc0202 has joined #osdev
the_lanetly_052 has quit [Ping timeout: 260 seconds]
mahmutov has joined #osdev
heat has quit [Ping timeout: 256 seconds]
sonny has joined #osdev
Ali_A has joined #osdev
<Ali_A> so I am filling the screen by writing to pixels at  address `0xA0000`  looping by (320*200 -1) however, I feel like the display kinda have gaps in it? is this normal? or is it related to qemu or what exactly?
<Ali_A> (this happens immediately after I boot and switch to 32-bit mode)
<bslsk05> ​pastebin.com: #include "my_types.h"#define YELLOW 14#define GREEN 2 #define VGA_SCE - Pastebin.com
<Ali_A> here is the code but I don't think the problem is there
<GeDaMo> Which video mode are you in?
<Ali_A> 0x13
<Ali_A> GeDaMo
<Ali_A> I used this website http://www.brackeen.com/vga/basics.html
<Ali_A> which says, do interrupt 0x10 while having ah = 0, al = 0x13
<bslsk05> ​www.brackeen.com: 256-Color VGA Programming in C - VGA Basics
<GeDaMo> Why have you declared VGAMemory as short* ?
<bslsk05> ​pastebin.com: ; bootloader.asm; A simple bootloader[bits 16];org 0x7c00 ; the addres - Pastebin.com
<Ali_A> here is the bootloader code I am using, I set the video mode to 0x13 in the beginning
<GeDaMo> Ali_A: VGAMemory should be char * or uint8_t *
<GeDaMo> Well, unsigned char *
<Ali_A> GeDaMo That worked, it seems I was having a problem since the bios memory for text mode uses unsigned short, this one just uses the unsigned char.
<Ali_A> I did change it before that, but now I noticed I changed the BIOSMemory pointer and not the VGAmemory but thanks! it is fully clearing it
<GeDaMo> Text modes use two bytes, one for the character the other for the attribute
<Ali_A> and I believe if I wanted text in this mode, I have to write my own bitmap font right?
<GeDaMo> Yes
<Ali_A> sounds a bit fun, going back to the old days + that helped a lot thanks!
bauen1 has quit [Ping timeout: 256 seconds]
bauen1 has joined #osdev
<GeDaMo> You can find bitmap fonts online, e.g. http://cvsweb.openbsd.org/src/sys/dev/wsfont/spleen5x8.h?rev=1.9&content-type=text/x-cvsweb-markup
<bslsk05> ​cvsweb.openbsd.org: src/sys/dev/wsfont/spleen5x8.h - view - 1.9
bauen1 has quit [Ping timeout: 248 seconds]
<zid> unifont is a free bitmap font
<zid> 'free'
pretty_dumm_guy has quit [Ping timeout: 276 seconds]
<MelMalik> how is terminus? is it goodL?
alpha2023 has joined #osdev
<mjg> mrvn: i know a guy who was teaching programming in college
<mjg> mrvn: he said most of the group submitted the same broken code with cosmetic changes
<mjg> mrvn: and which he recognized from the previous year
Brnocrist has quit [Ping timeout: 276 seconds]
Brnocrist has joined #osdev
Ali_A has quit [Ping timeout: 276 seconds]
Likorn has quit [Quit: WeeChat 3.4.1]
bauen1 has joined #osdev
pretty_dumm_guy has joined #osdev
<geist> MelMalik: I think i've used it and it's okay
<geist> as a side note i recommend the excellent Hack font
<geist> use it pretty much everywhere
<zid> I like unifont because it covers a decent amount of unicode
<zid> a lot of free fonts are really limited in that regard
<zid> nobody tell gnu I pirated their font
netbsduser has joined #osdev
<geist> oh good point
<gog> dear FSF i caught zid with ur warez
<mrvn> Is it bad behavior to recomment on stackoverflow for the user to contact another user so they can do the homework assignment together? :)
Likorn has joined #osdev
<mjg> mrvn: i suggest you drop stackoverflow to begin with
mavhq has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
mavhq has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
<sonny> so is good for indepth questions tbh
<geist> yah depends on whaty ou use it for really
gog has quit [Remote host closed the connection]
Likorn has joined #osdev
<mrvn> Note for code mining that's for sure.
<mrvn> -e
<mjg> dude what
<mjg> i removed my account so can't really point at anything now
<mjg> but i can give you a glimpse of surrealistic idiocy i went trhough on that shitsite
<mjg> wait, i may be able to google one nugget
<mjg> hrmpf, ez search fails
<mjg> for example there was a question about mmap vs syscall read/write performance
<mjg> some fucking twerp with 6 digit rep wrote an answer around 2011 or so
<mjg> quoting torvalds from 2002 or so
<mjg> that read/write is faster
<mjg> and stating that he doubts anything changed
sonny has quit [Ping timeout: 252 seconds]
<mjg> peak stackoverflow was when they were promoting "community documentation" (or maybe "community guides", can't recall the exact name)
<geist> sure. but that's the responsibility of the reader to sort through nonsense. as is in life
<mjg> for the #c tag the content was consistentnly fucking stupid
<mjg> in particular some guy copy-pasted a multithreaded link list producer/consumer
<mjg> ... except the code did not compiler
<mjg> compile
<mjg> and it lacked proper memory barriers, making it fail on ppc
<mjg> [i checked :>]
<geist> i'm sorry this makes you angry
<geist> your outie is a kind person
<mjg> i'm saying the content there is huge hit/miss and if you don't know upfront what makes sense, you are screwed
<geist> your outie makes people smile
<mrvn> mjg: well, mmap and write is a total nightmare and no-go.
<mjg> it really depends man
<mjg> for example if you have a multithreaded prog and tons of files to process (think multithreaded grep -r)
<mrvn> Try handling IO errors.
<mjg> ... linux will suffer greatly due to lock contentnion on vm
<mjg> and it's not a hypothethical either
<geist> server lasted 3 days in last configuration, doing a full reseat and putting everything back to original config
sonny has joined #osdev
<mjg> there is a grep-alike program named ag which slows down at some point if you spawn too many threads
<geist> after some use of deoxit
<mjg> ... and picks back up if you disable mmap
<mrvn> mjg: where does it suffer vm lock contentnion? On write or mmap-write?
<mjg> on calling mmap/munmap
<mjg> and subsequeent page faults
<mrvn> Sure. because that is process global.
<mjg> faults are handled with the semaphore taken for reading which blocks mmap/munmap
<mrvn> mmap is only ever good if you don't care about errors.
<mjg> now i wonder if linux finally got hugepage support for files
<mrvn> and then in moderation
<mjg> it used be that you only had them for anon mappings
<geist> huge mapping of a file sounds complicated as heck
<geist> though there are interesting situations on arches that support intermediate sizes that aren't as ridiculous
<mjg> freebsd has been doing it for over a decade
<mrvn> geist: how so?
<geist> oh i dunno, seems like it'd cause some interesting dirty page behavior, since suddenly it now dirties the entire block
<mjg> what does suck about it is the need to writeback 2MB if only a single byte changed
<geist> which i guess is doable, just sounds tricky
<mjg> or whateer your page size is
<mrvn> You could split a 2MB mapping into 4k chunks on drity.
<geist> obviously it's doable, but might have some wonky performance issues
<mjg> mrvn: sure, but then you may be combating the entire point if using a hugepage
<geist> true, could mark it RO, trap the write and split there
<geist> well depends on if the point is mostly in the read path
<geist> and write path just comes along for the show
<mrvn> mjg: you would get a better read behavior
<mjg> basically what does makes sense here is explicit request to have one
* geist nods
* mrvn nods
<mjg> i can easily imagine a prog which has a cache based on a hugepage'd file
<mjg> which writes very seldomly
<mrvn> Now I wonder how swapping deals with 2MB pages
<mjg> on linux they used to demote
<mjg> i don't know what's happening now
<mrvn> Say you do write to an mmaped file and the disk has an IO error. What do you think then happens? What should happen?
<mjg> say you fsync, it says saul goodman but it did no work
<mjg> what should happen then
<mjg> did not*
<mrvn> mjg: fsync returns EIO
<mrvn> assume you didn't msync yet
<mjg> is ti fixed?
<bslsk05> ​wiki.postgresql.org: Fsync Errors - PostgreSQL wiki
<mrvn> No idea if it is buggy or not but POSIX says fsync returns EIO on error.
<mjg> oh it is
<mjg> Linux < 4.13: fsync() errors can be lost in various ways; also buffers are marked clean after errors, so retrying fsync() can falsely report success and the modified buffer can be thrown away at any time due to memory pressure
<mjg> fixed past that
<mrvn> good to know. but back to mmap
<mjg> my general point being that trusting your data to be on storage requires a lot of faith
<mjg> ye, mmap can get you fucked
<mjg> you either can tolerate it or not, if not, don't use it
<mrvn> there is no EIO specified for msync(). So the kernel can't even report an IO error later when you do msync
<mjg> i'm guessing you would sync_file_range despite using mmap
<mjg> but again, i don't trust data to be safely recoverable from storage no matter how many :"flush everyting" calls you make
<mrvn> And then there is the obvious drawback that if you memcpy 4096 bytes into an mmaped file it first reads the old block just to overwrite it.
<mjg> if you are trying to say that there are cases where mmapping is a bad idea, i don't think it's much of a contested point
<mjg> also i don't know if you are trying to defened that SO guy or what
<mrvn> More. I'm saying mmap of a file is nearly always a bad idea. Only good use case I see is to use a big file as swap private to your app.
<mrvn> mjg: I haven't touched on the speed yet. :) I believe read/write done properly will be faster than mmap too.
<mjg> mmap will easily be a huge win if what you have is a big f-word file you just need to processes
<mjg> process
<mjg> read-only
<mrvn> yep. That's your private swap file usage.
<mjg> well can be if you it happened to use hugepages
<mjg> the moment you start writing we run into a lot of handwaving territory
<mjg> boiling down to "bench it"
<mrvn> Gimp stores the image data in mmaped files. Another good private swap file use case.
<mrvn> If you have data near or bigger than your ram then mmap is your friend, at least if you need random and partial access.
<mrvn> if you arte writing control software for a nuclear reactor then maybe stay far away from mmap.
<geist> heh freebsd 13.0 recommends i upgrade to a newer release because 13.0 is reaching EOL
<geist> but 13.1 isn't released yet
<geist> thoguh i guess the recommendation isn't strictly speaking nonsense. it's just timed such that it starts warning a bit too early, IMO
<mjg> tf you have freebsd for
<geist> <Gasp> heretical right!
<mjg> to be fair, 13.1 was supposed to be out but funny regressions resulted in delays
<geist> i have only prayed to linus 3 times today
<mjg> rc6 just built
<mjg> official release on may 16
<geist> yah probably just delays and they had some sort of hard EOL baked into 13.0, i'm guessing
<mjg> you reminded me of eler though
<mjg> lemme find the classic
<mrvn> maybe you should upgrade to openbsd or hurt?
<geist> it's one of my VMs. i keep around one of a lot of systems
<geist> freebsd, netbsd, openbsd, fedora, win10, etc
<mrvn> win95?
<geist> yes and xp and win2k and os/2
<mrvn> qms?
<mjg> no love for illumos? :)(
<geist> though i dont run those constantly because i have a whole private network for those
<geist> mostly because i dont want those getting anywhere close to the interwebs
<geist> mjg: actually i did have an illumos but it fell into disrepair
<geist> need to reinstall it. it got into some sort of update hell and i stopped fiddling with it
netbsduser has quit [Read error: Connection reset by peer]
<mrvn> I need to dig out my win95 from somewhere and my Siedler4 CD to play it again.
<geist> this is the primary thing i do with the server i've been trying to get stable again. it's a VM host
<bslsk05> ​geekz.co.uk: An actual woman – Everybody loves Eric Raymond
<mjg> geist: which illumos? i used to have omnios, but eventually it stopped being able to update to "bloody" and i gave up on it
<geist> was a few years back
<geist> i honestly dont remember. the VM file is floating around here somewhere but it was virtualbox at the time
<geist> would need to convert over
<mjg> i got free, net, open, dfly, omnios and TEMPLEOS
<mjg> forgot about that one
sonny has quit [Ping timeout: 252 seconds]
<mjg> any usage problems with illumos aside, it keeps eating CPU while idle
<mjg> i did some dtracing to figure out what's going on
<mjg> the kernel keeps having fun doing tons of avoidable maintanence work
<mjg> and most importantly zfs has fun constantnly generating i/o
<mjg> afair it was at about 15% cpu on my laptop while supposedly idle
sonny has joined #osdev
<mrvn> I'm daeth on that kind of behavior.
<mjg> also funzy. the vm is 2 thread. it runs into lock contention
<mjg> :)
<mjg> while idle
elastic_dog has quit [Ping timeout: 240 seconds]
<mrvn> Poll: Who is `using namespace std::literals;`?
elastic_dog has joined #osdev
elastic_dog has quit [Excess Flood]
<mjg> fuck man, i'm tracking my weight every day since march 17
<mjg> i just plotted it
<mjg> got from 69 kg to 76
<mrvn> intentionally?
<mjg> no
<mjg> now i'm slightly overweight
<zid> have you considered only eating foods ending with x
<mjg> like pizzax?
<zid> it's a good diet because your food options are so limited besides borax
<mjg> i could still have clorox
<mrvn> I only eat on days ending in y
<mjg> but no, i have not came to that yet
elastic_dog has joined #osdev
<mrvn> Ritter Sport chocolate has a flavour for every diet but I'm not sure if it has any that ends in x
<mjg> i just made up my own: peanut butter sandwitchx
<mrvn> no jelly?
<mjg> i thought pb&j is a USA thing
<mjg> also sounds gross
<geist> ugh, gcc 12 is even more aggressive about array bounds
<geist> seems to hate it any time you simply derefrence a memory address
<geist> because it claims it out of bounds of some sort of implicit zero length array
<mjg> you got [0] arrays?
<geist> yep
<mjg> just [] them
<geist> well, i mean it's not an array
<mrvn> geist: you mean (ptr*)0x423423; kind of things?
<geist> like if you just make a pointer to some address and deref it
<geist> yep
<geist> whats the canonical solution to that?
<moon-child> mjg: lox!
<mrvn> That's a regresion. The warning was supposed to catch access to NULL with a small offset
<moon-child> geist: iirc there was some bug
<geist> i remember there was some blab about it a while back
<geist> and iirc there was a lot of pushback to the effect of 'good programmers shoulnd't do that'
<mrvn> I don't think there is a solution for it yet. You have to turn off the warning for that.
<geist> thanks. sometimes when you're embedded the thing is literally right there and you need to deref it
<geist> yah
<mjg> hm. you would think this would be sorted out with freestanding
<mrvn> mjg: freestanding can do (*NULL).foo too
<moon-child> need -fno-delete-null-pointer-checks if you wanna play that kinda game
<geist> looks like making an array out of it doesn't help
<mjg> -fno-surprises
<mrvn> geist: volatile?
<mjg> not implementable
<geist> ie, int *foo = address; foo[2] is out of range
<geist> volatile doesn't seem to change anything
<mjg> can you make foo to be typed as an array
<moon-child> mjg: i wish. -fwrapv -fno-strict-aliasing -fno-delete-null-pointer-checks, still provenance rules tho...
<mrvn> geist: volatile int * volatile?
<geist> interesting, that seems to work around it
<geist> by making the pointer itself volatile
<geist> ie, `volatile int * volatile foo = (void *)address;`
<mrvn> mjg: There is no way to specify an array size for a literal address like 0xFE201000
<geist> then yuo seem to be able to deref foo all you want
<mrvn> by making it volatile the compiler can no longer reason about the content so it looses the info that it's a literal.
<geist> also sort of interestingly you can assign it null and then deref that
<mrvn> Drawback is that "foo[0] + foo[1]" will read foo twice.
<geist> thus allowing you to deref any pointer as an array offset
<mjg> maybe you can devolatile the final pointer and still keep the workaround working?
<geist> anyway, ugh this sucks
<mrvn> geist: It could be a hardware register where you write in a descriptor and then read out the address associated with the descriptor or something.
<geist> yes except thats not what this is
<geist> oh yeah i mean yeah
<geist> exactly. like where's the thing? it's here, cast a thing to it. BOOM YOU DIE
<geist> in this precise code i have a word that was written in firmware, at the fixed adress
mahmutov has quit [Ping timeout: 260 seconds]
<geist> i just want to read the word. becuase it's ltierally just there
<mrvn> Only thing that helps is getting all your hardware addresses out of the DT dynamically instead of hardcoding addresses. :)
<mrvn> (or disable the stupid warning)
<geist> yah it's really dumb
<geist> or at least not very helpful to low level programming. i hate to turn off warnings for edge cases like this, but still
<mrvn> gets lots of false positives wiht linux too. It's a wonder they haven't fixed it yet.
<mrvn> I want something like volatile uint32_t *periphery = (volatile uint32_t *)0xFE201000 __attribute__(("bounds", 0, 0x100));
<clever> volatile uint32_t* dlist_memory = REG32(SCALER_LIST_MEMORY);
<clever> // note, 4096 slots total
<clever> mrvn: that reminds me, could i slap a bounds on here? will it enforce checks when i do [i] against this array later?
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
<mrvn> clever: That's exactly what I want. You can't yet.
<clever> ahh
<mrvn> Maybe that should be something like volatile uint32_t dlist_memory[] = ... of some form?
<clever> the only solution i can see right now, is to create a struct that contains `uint32_t[4096]`
<clever> and then cast the addr to the struct
<mrvn> clever: yep, that works.
<mrvn> volatile uint32_t* dlist_memory = (volatile uint32_t[4096])(SCALER_LIST_MEMORY); ?
<clever> kinda, but the type of dlist_memory immediately throws that size part out?
<mrvn> nah, gcc should remember it
<clever> what if this was extern
<clever> and other modules accessed it?
<mrvn> Then it won't know what size it is and not give any warnings
<clever> yeah
<mrvn> This was to fix the problem that REG32(SCALER_LIST_MEMORY) is marked as size [0] and alway warns.
<mrvn> For extern use you need to change the type and struct with an array works best
sonny has quit [Quit: Client closed]
<mrvn> geist: you could put the address into the linker script and mark it extern.
<geist> also ugh, gcc 12.1 riscv seems to make you want to have to pass 'zicsr' to the march switch to allow yuo to get to CSR instructions
<geist> which are technically an extension, but seemed to be implicit before
<geist> so i add that (-march=rv64imaczicsr) and now it messes up my multilib matching
gog has joined #osdev
<geist> CSRs are control registers, so i think the idea of having it be an extension is either you're compiling user code which i think can't touch any CSRs because there arent any, or i guess maybe you can build an extremely deeply embeded core that doesn't implement interrupts or exceptions and thus never need to read any?
<mrvn> Not sure something like that should change the ABI for multilib
<geist> it does due to multilib string matching
<psykose> is that gcc or binutils 2.38 at fault? i've had to do the same on gcc11 and thought it was the latter from https://patchwork.ozlabs.org/project/uboot/patch/20220214053348.42803-1-raj.khem@gmail.com/
<bslsk05> ​patchwork.ozlabs.org: riscv: fix build with binutils 2.38 - Patchwork
<geist> ie, -march=rv64imac vs rv64imacfd etc
<psykose> (and i lost where the actual change is)
<mrvn> but it shouldn't.
<geist> psykose: oh it's probably binutils, youre' right. sicne the assembler is actually rejecting it
<geist> and yeah am using the current binutils in this case
<mrvn> or only one way
<geist> (just built new gcc 12.1 toolchain and trying it out)
<psykose> mhm
<mrvn> Code that uses CSRs can use libs that don't.
<geist> mrvn: well the multilib matching is not so much the problem, but its matching is very strict as it currently stands
<geist> but yes, strictly speaking it should probably only match on subsets of the march/mabi that would actually result in abi change in most cases
<mrvn> it's a hard problem and multilib is a nightmare
<geist> yah in the case of riscv the march line specifies things to pretty fine granularity
<geist> so you almost want the multilib matching in this case to have wildcards in it
<mrvn> I whish gcc would drop multilib and sysroot and use multiarch instead.
<geist> or some sort of more complex regex that it can probably do
<mrvn> how does multilib work with code that overloads functions for different arch sets?
<mrvn> The lib would have to match multiple multilib strings
sonny has joined #osdev
<geist> it doesnt
troseman has joined #osdev
Burgundy has quit [Ping timeout: 256 seconds]
srjek has quit [Ping timeout: 250 seconds]
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
vai has joined #osdev
vai is now known as Jari--
Likorn has quit [Quit: WeeChat 3.4.1]