<kof673>
it is a conspiracy, "they" want you to have a libc....
<kof673>
mips64 looks ok :D
simjnd has joined #osdev
* kof673
considers just calling functions manually for division, since don't use it often....slow, but would avoid this dependency, and gcc s that don't need those, can just use normal C code
<kof673>
(can just use normal C code inside the division function, that is) slow but........seemingly would work.........
<kof673>
it won't break anything...code that needs those will still just not compile lol just don't use division in C code, call a function instead lol
<kof673>
*will still just fail to link. slower even since these seemingly use a special calling convention either, and written in asm surely, but...........it would seemingly work.........
agent314 has quit [Quit: Konversation terminated!]
vdamewood has joined #osdev
<the_oz>
there has got to be a way to -ffreestanding-but-also-bonus
<the_oz>
-ftreestanding
<the_oz>
, better own, at least then you can put near usage for cache proximity
<the_oz>
betterimplement your own, at least then you can put near usage for cache proximity
<bslsk05>
stackoverflow.com: c - Undefined reference to '__divdi3' - Stack Overflow
<kof673>
its a horrible idea, just if i only like 5 divisions, it is feasible to just call a function lol i can just grab them using ar out of glibc or whatever, but just seems shaky... i wonder what musl does...
<kof673>
*only use like
<the_oz>
I WILL COPY THE BYTES FROM RUNTIME IF I WANT TO NO ONE CAN STOP ME
<the_oz>
reeeeeeeeeeeeeeeeeeeeeeeeeeeee
<kof673>
i don't like the idea of grabbing functions out of glibc, and then praying they work on "bare metal" this is all theoretical targets, just to get things to compile though
<kof673>
i mean, how "freestanding" is a random libc function? depends.....
<the_oz>
well copying from runtime assumes that where you land is where you should be, right?
<the_oz>
maybe determining that is harder than it appears
<kof673>
there is perhaps a hidden property of C functions, thread-safe, re-entrant...and....can i just take foo.o out of a libc and mix it with other code, freestanding or hosted? strlen() memcpy() those are probably ok...other stuff....who knows :D
vdamewood has quit [Quit: Life beckons]
GeDaMo has joined #osdev
<the_oz>
I know they do um... what is it with error things
<the_oz>
the one error ever
<the_oz>
yolo
<kof673>
errno? lol
karenw_ has quit [Remote host closed the connection]
<the_oz>
yes thank u
<GeDaMo>
"error in the error code handling routine" :|
karenw has joined #osdev
simjnd has quit [Ping timeout: 265 seconds]
karenw has quit [Ping timeout: 276 seconds]
simjnd has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
simjnd has quit [Ping timeout: 248 seconds]
xenos1984 has joined #osdev
<the_oz>
the THING THINK
simjnd has joined #osdev
jedesa has joined #osdev
simjnd has quit [Ping timeout: 276 seconds]
Lucretia has joined #osdev
simjnd has joined #osdev
simjnd has quit [Ping timeout: 252 seconds]
simjnd has joined #osdev
simjnd has quit [Ping timeout: 276 seconds]
simjnd has joined #osdev
stolen has joined #osdev
jjuran has quit [Quit: Killing Colloquy first, before it kills me…]
jjuran has joined #osdev
<nikolar>
geist: yeah riscv is a really lame arch
<nikolar>
The only thing going for it is that it's an open arch
<bslsk05>
codeberg.org: osdev/libgcc-binaries: Precompiled binaries of the libgcc GCC/clang runtime support library. - Codeberg.org
netbsduser`` has joined #osdev
<kof673>
eh, libgcc is enough to compile for sh32, i am just getting things to compile for gxemul bare targets lol it is picky about where it is on the link line though, but i have LD_EXTRA_OBJS and such to append random objects or libraries to every program that gets linked
<kof673>
the example gxemul "hello" program for a test machine doesn't do any division, so doesn't run into these things actual code also needs
Left_Turn has joined #osdev
Turn_Left has joined #osdev
scaleww has joined #osdev
Left_Turn has quit [Ping timeout: 248 seconds]
<kof673>
i think it is just alpha that expects math ops in "c library" ... out of arm mips64 ppc32 riscv64 sh32 sparc64 they either don't need such gcc math ops or libgcc has them.. (mips32, gxemul example just re-uses mips64 toolchain with different arguments, so didn't build a separate toolchain for that to get 32-bit libgcc)
<kof673>
alpha libgcc.a has other such ops seemingly, but not __divl __divq :/ anyways :D
neutrino777 has joined #osdev
neutrino1 has quit [Ping timeout: 260 seconds]
wereii has joined #osdev
goliath has joined #osdev
carbonfiber has joined #osdev
stolen has quit [Quit: Connection closed for inactivity]
scaleww has quit [Remote host closed the connection]
surabax has joined #osdev
<pie_>
i guess syslinux doesnt have any sort of non-dead upstream?
<pie_>
im booting a livecd (grml) on a supermicro server and accessing it over the BMC serial console, things generally seem to work. ive configured isolinux to show up on the serial console, and it _does_, but i cant seem to give it any sort of input. the physical keyboard does work ... :/
<pie_>
does anyone have any ideas?
<pie_>
super grub 2 disk seems to work fine
Turn_Left has quit [Remote host closed the connection]
Turn_Left has joined #osdev
<GeDaMo>
Is it a USB or PS/2 keyboard?
<pie_>
ps2
<pie_>
to clarify, the ps2 keyboard works, but typing into my terminal with the IPMI serial over lan stuff doesnt do anything, grub2 works perfectly fine with its own serial stuff
alexander has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
alexander has joined #osdev
the_oz has quit [Ping timeout: 276 seconds]
the_oz has joined #osdev
<pie_>
hrmph, ive set up a *similar* test in qemu and that seems to work...
FreeFull has joined #osdev
joe9 has joined #osdev
netbsduser`` has quit [Ping timeout: 260 seconds]
netbsduser`` has joined #osdev
* kof673
tests out chibicc, verifies can -S to asm then assemble using x86-64 assembler and run hello world with qemu-x86-64. tries using symlinks to ar as gcc ld and updating PATH....apparently it fork bombed and launched 100s of copies of as or a script lol
<kof673>
i think i will make a script instead lol
<kof673>
i had wrapper scripts to use -m64 etc....but i named my symlink for chibicc same name to try to trick chibicc :/ as script -> calls as (first script now top of PATH) -> calls as -> calls as ->
troseman has joined #osdev
troseman has quit [Client Quit]
troseman has joined #osdev
troseman has quit [Client Quit]
vdamewood has joined #osdev
blockhead has left #osdev [#osdev]
chiselfuse has quit [Ping timeout: 264 seconds]
xenos1984 has quit [Ping timeout: 276 seconds]
xenos1984 has joined #osdev
carbonfiber has quit [Quit: Connection closed for inactivity]
xenos1984 has quit [Ping timeout: 245 seconds]
xenos1984 has joined #osdev
simjnd has quit [Ping timeout: 260 seconds]
HumanG331 has quit [Ping timeout: 265 seconds]
joe9 has quit [Quit: leaving]
simjnd has joined #osdev
Turn_Left has quit [Read error: Connection reset by peer]
simjnd has quit [Ping timeout: 276 seconds]
the_oz has quit [Quit: Leaving]
Left_Turn has joined #osdev
Left_Turn has quit [Remote host closed the connection]
simjnd has joined #osdev
simjnd has quit [Ping timeout: 276 seconds]
xal has quit [Quit: bye]
xal has joined #osdev
nyah has joined #osdev
karenw has joined #osdev
troseman has joined #osdev
troseman has quit [Client Quit]
simjnd has joined #osdev
simjnd has quit [Ping timeout: 252 seconds]
vdamewood has quit [Quit: Life beckons]
chiselfuse has joined #osdev
Left_Turn has joined #osdev
Turn_Left has joined #osdev
Turn_Left has left #osdev [#osdev]
Left_Turn has quit [Ping timeout: 260 seconds]
simjnd has joined #osdev
surabax_ has joined #osdev
surabax has quit [Ping timeout: 252 seconds]
simjnd has quit [Ping timeout: 276 seconds]
aejsmith has quit [Remote host closed the connection]
aejsmith has joined #osdev
surabax__ has joined #osdev
<Ermine>
If open(2) returns ENODEV on linux, I can be sure that's a kernel bug?
<Ermine>
(from man 2 open)
<heat>
that's not a kernel bug
surabax_ has quit [Ping timeout: 265 seconds]
<zid>
The man page says it's a documented non-conformance and it should instead be returning ENXIO
<Ermine>
kek
<Ermine>
i see now
<heat>
> This is a Linux kernel bug; in this situation ENXIO must be returned.
<heat>
huh TIL ok it is a kernel bug
<zid>
It was a bug, now it's a documented QUIRK
<zid>
can't fix it cus it'd break things
<Ermine>
but in my case it's a usb device, and if i open it, it gets reconnected
<Ermine>
that doesn't happen on arch with the same kernel version of 6.14.3, so it must be something in opensuse patches
<Ermine>
heat: i'm trying to open a specific usb device (through libusb_open, which obviously calls open on device file in /dev/bus/usb), but open returns ENODEV and device gets disconnected and connected with different address
<heat>
weird. can this be a udev thing?
<heat>
does dmesg say anything interesting?
<heat>
or udevd logs
<Ermine>
nothing in udevd logs
<Ermine>
in kernel logs, only reports on disconnect and reconnect
<heat>
can you open a bug report in the bugzilla?
<heat>
tumbleweed is, apart from the patches above, fully upstream, latest mainline stable release
<heat>
for leap the possibility of a bad/missing backport woud definitely be real, not here though
steelswords94361 has quit [Read error: Connection reset by peer]
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
steelswords94361 has joined #osdev
marr-ales-fios has quit [Remote host closed the connection]
<geist>
qemu v10 was released
<heat>
block: virtio-scsi multiqueue support for using different I/O threads to process requests for each queue (similar to the virtio-blk multiqueue support that was added in QEMU 9.2)
<heat>
WOOOOOOOOOOOOOOO
<heat>
other details are sparse so i can only WOOOOOOOOOOOOOOOOO for that