Dead_Bush_Sanpai has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpai has joined #osdev
xenos1984 has joined #osdev
<ramenu>
oh so someone bought the domain just for the memes
<kof673>
no idea, i assume that part is genuine lol > The core idea of Poe's Law is that a parody of something extreme can be mistaken for the real thing
<the_oz>
kernal.org has been bought sincce 2001
kof673 has quit [Ping timeout: 240 seconds]
goliath has quit [Quit: SIGSEGV]
cow321 has quit [Ping timeout: 245 seconds]
the_oz has quit [Read error: Connection reset by peer]
Fingel has joined #osdev
Gooberpatrol66 has joined #osdev
Gooberpatrol_66 has quit [Ping timeout: 245 seconds]
rlittl01 has quit [Ping timeout: 276 seconds]
Fingel has quit [Quit: Fingel]
Fingel has joined #osdev
Fingel has quit [Client Quit]
Fingel has joined #osdev
SophiaNya has quit [Remote host closed the connection]
ptrc has quit [Remote host closed the connection]
SophiaNya has joined #osdev
ptrc has joined #osdev
steelswords94 has quit [Read error: Connection reset by peer]
steelswords94 has joined #osdev
kof673 has joined #osdev
cow321 has joined #osdev
aethlas_ has joined #osdev
aethlas has quit [Ping timeout: 252 seconds]
hwpplayer1 has joined #osdev
freakazoid332 has quit [Ping timeout: 260 seconds]
Fingel has quit [Quit: Fingel]
hwpplayer1 has quit [Quit: bbl]
Dead_Bush_Sanpai has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpai has joined #osdev
melba_ has joined #osdev
_ngn has quit [Remote host closed the connection]
_ngn has joined #osdev
kof673 has quit [Ping timeout: 240 seconds]
theyneversleep has joined #osdev
craigo has joined #osdev
heat has joined #osdev
jedesa has quit [Quit: jedesa]
netbsduser has joined #osdev
GeDaMo has joined #osdev
jedesa has joined #osdev
goliath has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
emntn has quit [Ping timeout: 248 seconds]
emntn has joined #osdev
hwpplayer1 has joined #osdev
emntn has quit [Ping timeout: 252 seconds]
emntn has joined #osdev
raphaelsc has joined #osdev
vursc has joined #osdev
cow321 has quit [Ping timeout: 252 seconds]
karenw has joined #osdev
hwpplayer1 has quit [Read error: Connection reset by peer]
hwpplayer1 has quit [Remote host closed the connection]
vursc has quit [Ping timeout: 260 seconds]
gareppa has joined #osdev
vursc has joined #osdev
theyneversleep has quit [Remote host closed the connection]
m3a has quit [Ping timeout: 248 seconds]
the_oz has joined #osdev
karenw has quit [Remote host closed the connection]
gorgonical has joined #osdev
<gorgonical>
I come bearing questions
<gorgonical>
If I use -fdata-sections and -fffunction-sections along with -Wl,gc-secctions should I expect the final ELF to still assign everything to separate sections, or to collapse them in the end to a single .text section or whatever?
kof673 has joined #osdev
spare has joined #osdev
<heat>
honestly dunno, you should check
<nikolar>
depends on your linker script
<nikolar>
by default, i think it collapses
<heat>
yeah probably
<heat>
if you're using GNU ld you can check the default linker script with -v IIRC
<nikolar>
ld -v ?
<heat>
yeah
<heat>
uh no, --verbose
<gorgonical>
This is in the context of trying to eliminate unused code that gets linked in from .a files
<heat>
have you tried making a proper .a? kthxbye
<gorgonical>
I have not yet, new project
<gorgonical>
new-to-me anyway
<heat>
the libc is the perfect example of a nicely working .a by putting each function (or closely related functions) in their own TU
<heat>
cuz .a symbol resolution just loads one .o for a symbol
<nikolar>
this should work too though, -fdata-sections -fffunction-sections -Wl,gc-secctions
<gorgonical>
what do you mean by that
<gorgonical>
nikolar: it should and the lib.a shows that the functions are all assigned to their own sections, but unused functions end up in the final ELF anyway
aethlas has joined #osdev
<gorgonical>
with .a archives it's just a direct name match, right?
<nikolar>
?
<gorgonical>
for symbols being provided
<heat>
wdym
aethlas_ has quit [Ping timeout: 265 seconds]
karenw has joined #osdev
<clever>
2024-10-18 10:39:42 < gorgonical> This is in the context of trying to eliminate unused code that gets linked in from .a files
<bslsk05>
github.com: hold/src/elf/link.c at master · heatd/hold · GitHub
<bslsk05>
github.com: musl/src/stdlib at master · heatd/musl · GitHub
<clever>
gorgonical: i believe by default (without any function/data sections or linker gc), when it links to a given .a file, it will only include some of the .o's within it
<heat>
link 1 has notes on linker symbol resolution and static library tricks, link 2 is a perfect example of a well structured static library
<gorgonical>
I mean that when you generate the .a file the functions get named a certain way. When the linker builds the final elf it's just matching clals to foo in the main.c to some function in a linked .a called foo also, right?
<clever>
so if libfoo.a contains bar.o and baz.o, and you only reference symbols in bar.o, then baz.o just entirely gets ignored
<gorgonical>
hmm
<heat>
yes
<heat>
what clever said
<clever>
function-sections and data-sections let you get just part of bar.o, so you can reduce things further
<gorgonical>
Okay, I'll take a look at this then
<heat>
note that the libc approach isn't trivial and may not be super possible for your library, idunno
<nikolar>
heat: calling musl perfect???
<nikolar>
whaaattt?
<heat>
it's very well structured
<clever>
yeah, ive noticed a lot of libc's are sort of doing function/data sections manually
<heat>
the weak binding trick is super funny
<clever>
one function per .c file, so you get one function per .o
Left_Turn has joined #osdev
<clever>
and then you get similar benefits, without having to turn on linker gc
<heat>
and works effectively to minimize the .o's you bring in
<heat>
oh also note that turning on LTO will also do symbol GC (not linker-level GC though)
<nikolar>
except that putting every function into it's own file is annoying as hell
<clever>
nikolar: yep
<heat>
that's life innit
<clever>
-ffunction-sections gives you similar results almost for free
<kof673>
i'm amazed because i've seen this convo before and usually that is the consensus: too much work
<clever>
the downside, is the cost of inter-function calls
<kof673>
where is heat and what have you done with them
<nikolar>
clever: is it?
<heat>
kof673, hi im heat how are you
<clever>
without function-sections, gcc/as know the distance between 2 functions at assembly time
<gorgonical>
The unused functions are in the same .o in the archive, but in their own sections. So by default all of the unused functions would be included anyway
<gorgonical>
But with the gc-sections that shouldn't happen
<clever>
so it can use a pc-relative call, with a small addr offset
<heat>
i'd be amazed if whatever awful architecture this is can't relax those jumps
<heat>
if it even matters
<clever>
with -ffunction-sections, gcc/as have no clue where the linker will put a function, and tend to use a full 32/64bit immediate load, that the linker fills in
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
<nikolar>
just -flto if if it's that important
<heat>
writing a linker is very fun btw and yall should try it
<nikolar>
i did, it was fun
<clever>
yeah, LTO basically solves everything, then you dont need data/function sections or linker gc
frkazoid333 has joined #osdev
<heat>
nikolar, did you get the GOT relaxation shit going?
<heat>
my linker isn't super useful because of that
<immibis>
before LTO people did amalgamation builds like in sqlite
<immibis>
just #include all the source files into one file and compile that. of course the source has to be set up for that.
<gorgonical>
i don't know if I can use LTO here because of how the project is structured
<nikolar>
heat: oh no, it was a uni assignment for a shitty made up arch
<heat>
ah
<nikolar>
still fun though
<clever>
immibis: i tried doing that once on a recent project, turns out, weak symbols dont like it
<heat>
my problem is that basically all .a's (through -fPIC and default PIE) have GOT relocations and the sort, and you're kind of expected to relax those into direct references and shit
<nikolar>
heat: i did want to write a proper linker considering that everything that exists is hyper complex
<clever>
#define WEAK __attribute__((weak))
<clever>
void WEAK HandleKey( int keycode, int bDown ) {
<heat>
and the one bit i don't really grok in ELF is the dynamic linking stuff (and TLS. fuck TLS)
<nikolar>
eww spaces around the argument list
<heat>
eww hungarian notation
<immibis>
that's part of "the source has to be set up for that." you can't always compile random source files that way
<clever>
immibis: basically, i defined a dummy fucntion like this, to do nothing, and then if the makefile decides to link in a second file, it can override things
<immibis>
nikolar: so did the gnu binutils people. twice. that's why gnu binutils has three linkers.
<clever>
immibis: but if you put the weak and normal function into the same unit, and try to compile it, gcc yells
<clever>
nikolar: previous author did that :P
<nikolar>
and except that all 3 linkers are a mess sort of lol
<immibis>
so you write #if !AMALGAMATION || !USE_REAL_IMPLEMENTATION
<clever>
immibis: and i was using weak just to avoid having to use #ifdef to comment out the dummy
Gooberpatrol66 has quit [Ping timeout: 276 seconds]
<gorgonical>
Turns out that gc-sections does do something for that binary, so it's not just doing nothing. But it's still including code I don't think it uses. But this codebase and rust in general are unfamiliar to me so maybe there's something else going on
<nikolar>
oh you're doing rust
<nikolar>
good luck
<gorgonical>
i know
<gorgonical>
:(
<gorgonical>
At least this isn't a pointless optimization exercise--there's real hardware repercussions for not removing bloat from this binary
<nikolar>
why are you using rust if you care about bloat :P
<gorgonical>
I cannot make such decisions
<karenw>
To write an os you must first construct a universe
<gorgonical>
If we could compile this specific binary with clang instead of gcc I could maybe use linker-time lto and that might figure it out
<Ermine>
why do I get garbage instead of 0xaa55 from pci rom bar
<zid`>
why would you get aa55
<zid`>
oh pci option rom for booting, and you're at offset 510?
<Ermine>
not oprom
<zid`>
then why are you expecting aa55
<Ermine>
linux expects that as a header
melba_ has quit [Quit: Two pure functions walk into a bar. Nothing happens.]
<zid`>
ah, because this is some specific device you're trying to write a driver for?
<Ermine>
from memory pointed at by expansion rom base address
<Ermine>
yes, that's a specific device
<Ermine>
which supposed to give out VBIOS with no strings attached
<zid`>
vbios should be bootable
<zid`>
cus it installs the int 10h handler
<zid`>
so that the graphics functions hit the vbios
<Ermine>
drm drivers load vbios as well, I guess to extract some data from it. Well, I don't have clear understanding of this
<kof673>
gog has 9 lives and will be reborn in spirit and come back with a vengeance
<kof673>
as it is written
xenos1984 has quit [Ping timeout: 246 seconds]
spare has quit [Remote host closed the connection]
xenos1984 has joined #osdev
vdamewood has joined #osdev
goliath has joined #osdev
LBeatrix has quit [Ping timeout: 260 seconds]
xenos1984 has quit [Quit: Leaving.]
cow321 has joined #osdev
xenos1984 has joined #osdev
<nikolar>
so anyone know what's the status of intel apx?
<nikolar>
(the extension to increase the number of registers to 32 amongst other things)
<nikolar>
(not the failed intel iAPX 432 processor)
raphaelsc has joined #osdev
craigo has quit [Remote host closed the connection]
<geist>
yeah i dunno. i'll ask around at work, though i dunno if what i hear will be public knowledge
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
<geist>
but i was curious too. and if so will AMD pick it up too
<nikolar>
i assume so
<nikolar>
especially with the recent events
<nikolar>
also ask around about the x86s too :P
<heat>
x86s? more like x86shitty
<heat>
upvote
<nikolar>
yes
<nikolar>
don't you dare touch my real mode
<kof673>
not too sidetrack but if we are going to nitpick "specie is the only constitutional money in this country" -- 1856. it is just one giant never-ending bankruptcy failure :D
<geist>
my main issue that may affect zircon (or other microkernels) is you simply cannot do port io in ring 3 anymore
<Ermine>
heat: https://tpaste.us/r5ox (that's on the older kernel). Also it happens that on apple machines there's no PCI expansion ROM, so it gives out garbage
<geist>
that being said aside from some legacy things that's probably not a big deal anymore
<heat>
monolithic kernels epic win
<geist>
but theni 'd be happy to remove io port bitmap logic in the context switcher
<geist>
and the TSS and all that other shit
<nikolar>
heh
<Ermine>
hi geist
<geist>
hola
floouuu has quit [Quit: Verlassend]
<heat>
>Expansion ROM at 90020000 [disabled]
<heat>
that sounds kind of worrying but all my devices also say [disabled]...
<heat>
i don't really recall many of these deets
<Ermine>
you need to write 1 into it first
<geist>
i think that's pretty common. i think there's some config space thing you have to do in PCI to map in expansion rom
<Ermine>
because bit 0 of this bar is for enable/disable
<heat>
yeah im just wondering if the driver is doing it
<Ermine>
pci core does that
<geist>
the driver probably just doesn't care so it doesn't enable it yeah
<Ermine>
when you do pci_rom_map
<heat>
in any case it might be that the OPROM just doesn't match whatever the driver is expecting? in the case it's some really weird bespoke format
<heat>
like, if decoding is disabled i'd expect all-1s
<heat>
could also be that the driver needs some hacky delay between some of the steps, who knows
<Ermine>
radeon has hacky path for this case, it doesn't work either
<geist>
i thought there was something special other than it being in a BAR. isn't the expansion rom address in a dedicated field in the config space?
<heat>
yes
<Ermine>
Seems like this is just Apple thing
<heat>
i think the oprom field is BAR-ish though
<Ermine>
linux seems to treat it as 6th BAR
<Ermine>
and it checks the header in the core, so I guess everything has to have 0x55aa signature
the_oz has quit [Ping timeout: 252 seconds]
<Ermine>
so it's just apple thing
<geist>
does remind me i was interested a while back what in the real world the expansion rom looks like for things like ethernet or nvme
<heat>
there's a standard format yeah.
<geist>
with the idea that does it provide legacy + UEFI drivers, etc
<heat>
if you find an EBC EFI driver post that shit
emntn has quit [Quit: WeeChat 4.4.2]
<Ermine>
In the other news, seems like cat /sys/bus/pci/devices/whatever/rom doesn't work?
<Ermine>
it gives EINVAL if you just cat it and EIO if you write 1 to it and then cat
<heat>
yeah you might need to enable it? i remember some shitty shenanigans for the i915
emntn has joined #osdev
<geist>
maybe there's a kernel commandline switch that tells the PCI bus to map everything up front
<heat>
anyway geist yeah losing the ring3 ioport stuff is a little sad
<heat>
but you can probably just handle the traps kind of okay?
<geist>
other than that it's a little clunky how they do things, but for the most part it does what you expect
<geist>
yah
<heat>
in/out is kind of okay to decode i think
Arthuria has quit [Ping timeout: 272 seconds]
<heat>
there are funny forms: rep outsb and rep insb
<geist>
yah and there are already syscalls to enable/disable particular io port ranges per process, so it'd be easy to jsut do that and then trap+emulate
<heat>
which i've heard give you real speedups under KVM
<geist>
instead of inventing another syscall and capability to make you call
<nortti>
what all requires the use of ioports nowadays? I'd expect most hardware to support MMIO-only operation if it's to be used on other architectures
<geist>
right, exactly. same with using io ports for virtio/etc kicks, because it's easier to decode
<heat>
legacy stuff
<geist>
though modern virtio i think puts all of the kicks in a separate page, so you can simplify the decoding on the KVM side by just saying any write to that page is valid
<geist>
no need to decode it
<geist>
nvme does too, i think. page aligned kicks
<heat>
kicking things is bad mkay
the_oz has joined #osdev
jeaye has quit [Ping timeout: 246 seconds]
jeaye has joined #osdev
<netbsduser>
it's interesting someone decided that microkernels should have drivers in userland
<geist>
that's kinda the point
<geist>
it's one of the major 2 or 3 tenants of microkernels
<netbsduser>
it wasn't until some point later
<geist>
oh possibly, i'm not entirely well versed on very early microkernel design
<netbsduser>
i consulted the microkernels of the late 80s and very early 90s and found they usually have most direct device drivers in the kernel
<heat>
maybe because it was mindboggingly slow to have them in userspace?
<heat>
versus just 'slow' these days
<geist>
not particularly, that's the trick. you can do a lot of fun tricks to help
<geist>
oh was. yeah
* kof673
.oO( synthesis os as microkernel )
<netbsduser>
heat: it was never discussed even as a compromise, so we can conclude that it was obvious to the inventors of microkernels that direct device drivers go in the kernel
<heat>
the huawei paper they linked on the fuchsia discord basically just does "lol what if we still move a lot of stuff to the kernel"
<heat>
although i think they do funky stuff with task switching and IPC
karenw has joined #osdev
<geist>
yeah the huawei thing i dunno what they're up to to be honest
<geist>
at some point it was really talking about using virtualization as a process boundary, etc
<netbsduser>
looking at the 1985 paper "Mach: A New Kernel Foundation for Unix" the propsoed architecture for "Kernelising BSD" (their goal of becoming a microkernel not the monolithic kernel it was initially) they place "Low-level device drivers" in the "Mach-1 Kernel Layer"
<geist>
netbsduser: i'm not entirely sure i agree that they did it that way, but honestly i haven't looked at early mach or its predecessors
<geist>
mmm interesting
<heat>
what's a "low-level device driver" though?
<geist>
though maybe part of the point there is they're trying to build something for unix, so they started with existing drivers or whatnot
<geist>
tis true, i mean we have a handful of drivers in the kernel in zircon too, because you have to
<geist>
it's just all the non core stuff
<geist>
(ie, not timers, interrupt controllers, cpu stuff, etc)
<geist>
all the non core stuff in user spcae that is
<netbsduser>
geist: if so then either someone else influential on fuchsia did, or it somehow parallels mach in quite specific ways by accident or convergent evolution
<netbsduser>
the "exception channel" concept is identical with mach's "exception port"
<heat>
well it's the obvious way of doing it
<geist>
yeah i have honestly no experience with mach, quite specifically. when we were laying down the initial design i purposely didn't want to pollute my brain with existing designs
<netbsduser>
heat: anything that's not "Unix File System, Unix Process Management etc." or "Secure network IPC, Distributed Filesystem, Authentication, Authorisation, Network Resource Management, Network Paging"
<geist>
same with pager objects and whatnot. it's the only obvious way to deal with demand paging files from kernel space
<heat>
whereas other microkernels take insane ways of doing things (userspace paging, literally EVERYTHING as a filesystem)
<heat>
zircon is a little saner
<heat>
it also started as kind of a monolithic kernel anyway
<geist>
we just pulled everything out that we didn't need
<geist>
where we really got off in the weeds is we had some initial design constraints so our IPC had to be a particular way
gog has joined #osdev
<geist>
so you end up with the pseudo-abomoination that is channels
<geist>
but that was a design requirement because of Reasons
<heat>
gog
<geist>
but was better to do than to endlessly dither about designs. thats why we succeeded vs the other 100 attempts for someone to write a kernel + OS within google over the years
<geist>
so starting with LK and getting a quick prototype, getting to hello world within a matter of weeks was a great move. it got us treated seriously
<heat>
should've written another unix
<heat>
the world needs more unices
* geist
points to starnix
<heat>
thank you for filling the unix quota.
tjf has quit [Quit: l8r]
tjf has joined #osdev
* geist
salutes
<geist>
for the glory of mankind
<heat>
you're just missing some manpages
<heat>
time to brush up on your roff
<netbsduser>
when i get this copy of the AIX book i've ordered from the states i can't guarantee i won't contribute another unix to the world
<heat>
i found a fun AIX technical document with an API listing on the interwebs
<netbsduser>
their vnodes are actually namecache/dent nodes btw, they call their actual vnodes "gnodes" and multiple aix-vnodes can alias one gnode. and they can do similar fun tricks with bind mounts
<netbsduser>
(it was discussed in pate's "Unix filesystems" but i never appreciated the significance at the time until i went back a few days ago to look)
gareppa has quit [Quit: WeeChat 4.1.1]
<kof673>
looking for something else...i noticed they had an itanium port....no emulator for it of course, except intel maybe had some internal thing.
<gog>
heat
<heat>
gognix kernel
<gog>
i'm nto writing a kernel
<gog>
why would i do that
<gog>
have you seen the kind of consequent madness that is wrought through kernel writing
<clever>
so in this case, the syscall returns 190 files
<clever>
and then `readdir()` pops them off the list, and returns them to the app, 1 at a time
<heat>
correct
<kof673>
it gets better, old bsd IIRC and next had: #definedirect dirent pre-posix perhaps
<clever>
also, at one time, glibc would call the 32bit only variant when using a 32bit userland
<clever>
and if the inode# was over 32bits in size, it would EOVERFLOW
<clever>
and a surprising number of programs, assume that readdir cant fail, and any abnormal return value means EOF
<clever>
(if the program was not compiled with large-file support)
<clever>
in my case, it was a 32bit userland, on a 32bit arm kernel, acting as a nfs client
<clever>
with a 64bit nfs server, and an xfs on a 4tb disk
<clever>
and xfs will generate an inode# over 32bit in size, if the first datablock is >1tb into the block device
<nikolar>
kof673: even better, old unix read directories with read directly
<heat>
my surprise really is that the mount abstraction just breaks in readdir()
<clever>
and *boom*, random utilities claim file not found, when it clearly exists
<heat>
i don't know how other unices handle this
<nikolar>
kof673: even better, old unix read directories with read directly
<heat>
kof673: even better, old unix read directories with read directly
<kof673>
messagen
<nikolar>
eh?
<clever>
yeah, ive heard of that, it just gets the raw filename list right out of the fs metadata
<kof673>
plural :D
<clever>
treating the dir as a file
<nikolar>
clever: exactly
<clever>
but once you support 2 FS's, that idea breaks down
<nikolar>
i guess you just get the directory struct from the stdlib and read into it
<nikolar>
and boom done
<heat>
i think netbsd still supports read() on dirs?
<clever>
so you need a VFS layer that gives a consistent view
<nikolar>
heat: it probably converts into some standard thing
<heat>
i mean... getdents could easily have been read()
<nikolar>
true
<clever>
yeah
<heat>
problem really is that cat <dir> would not ENOTDIR
<heat>
sorry, EISDIR
<clever>
heat: well, there is the open flag O_DIRECTORY
<clever>
cat doesnt use that, so it would fail to open
<heat>
no?
<heat>
O_DIRECTORY just means it fails to open if its not a directory
<karenw>
Huh, qemu TCG now supports x2apic.
<heat>
int fd = open("dir", O_RDWR); works just fine
<karenw>
Feels bad trying to configure the lapic via memory now.
<heat>
why? it's mostly transparent
<clever>
heat: ah your right, it does fail that way
<clever>
but couldnt it just be modified, to behave more like i said? what would break?
<heat>
i mean, if you want to check if its a dir, the only way would be to either stat() it beforehand, or try to open it with O_DIRECTORY
<heat>
there's no O_REGULAR (yet) nor would it be desirable for ca
<heat>
t
<karenw>
heat: was that to me? Originally I wanted to only support x2apic, but the only platform that I cared about that didn't support it was the qemu tcg. Then I updated qemu and it now works. Shouldn't be too hard to abstract out though.
<heat>
karenw, yeah i mean, the difference between x2apic and the apic is pretty small. basically a couple of ifs
Dead_Bush_Sanpai has quit [Ping timeout: 260 seconds]
<karenw>
It's just a faster and easier way to set the same registers for the most part, right?
Dead_Bush_Sanpai has joined #osdev
<heat>
not really faster AFAIK, it's just a more modern way of doing things
<heat>
fixes some little flaws in the original APIC (some IPI stuff, also unlocks the core count)
<karenw>
Yeah, was gonna mention the core count issue, but that's kinda irrelevant for hobbyist stuff :D
<karenw>
4G-1 max cpu cores (up from 256)
<karenw>
*255
_ngn has quit [Ping timeout: 260 seconds]
_ngn has joined #osdev
Left_Turn has quit [Read error: Connection reset by peer]
<netbsduser>
heat: the original 9p protocol does that
<netbsduser>
read = readdir
<netbsduser>
9p2000.L (the L stands for "Linux affinity", which is another way of saying "we tore out the plan9 stuff and put linux vfs operations in instead) brings back readdir though