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