<bslsk05>
github.com: all: binaries too big and growing · Issue #6853 · golang/go · GitHub
<heat>
rust doesn't have reflection
<zid>
2013, bug report for hello world being 2MB, it has... only grown as far as I know
<clever>
note: currently hard linking saves 12873.25 MiB
<clever>
330 store paths deleted, 2991.01 MiB freed
<clever>
heat: i ran a GC, and nix found 2.9gig worth of things it could delete
<clever>
but i'm still at 94 libc.so's, lol
<zid>
heat: idk the terms for it, but there's a bunch of meta crap it needs for backtraces or whatever it's doing with all that info
<clever>
-r--r--r-- 1 root root 509 Dec 31 1969 /nix/store/xak9ws5qs8g8cngvw45b2yrj896kk9pn-glibc-2.32-10-armv6l-unknown-linux-gnueabihf/lib/libc.so
<heat>
debug info?
<heat>
C also has that
<zid>
lots of companies are avoiding rust/go just because of all that data acting like shipping your C project as an .a :P
<clever>
heat: this one for example, is a cross-compiled armv6 libc, thats in use by something i forgot to delete
<zid>
You can't even remove it in Go
<zid>
because it *is* part of the language spec
<zid>
so it breaks backtraces and stuff if you strip it, which there isn't an official tool for to begin with
<clever>
if i delete that, and re-GC ....
<clever>
zid: even C and breakpad (a google util) lets you get usable backtraces, even from a stripped binary!
<zid>
what?
<clever>
it will save a copy of the symbol info, server side
<clever>
so when an end-user reports a symbol-less backtrace, the server can pull up the symbol info, and add it back in
<zid>
still have no idea what point you're trying to make
<clever>
breakpad is a framework for capturing the stack trace when things fault, and reporting it back to the author, without the end-user getting the symbol info
<zid>
'even C' wtf?
<clever>
comparing basic C stuff, to go
<zid>
of.. course C has backtraces
<zid>
when was that up for debate lol
<clever>
my point, was that C can get a useful backtrace with symbol info, even if the binary that faulted was stripped
<clever>
while your saying that go cant?
<zid>
I'm saying you can't strip a go binary
<heat>
google search says you can
<zid>
You can fake it, by changing all debug info to be "line 0 character 0, name ''"
<zid>
with a 3rd party tool
<zid>
but it breaks the language
<zid>
reflect is part of the core lang
<heat>
no, doing actual strip or passing some ld flags
<heat>
debug info is not reflection
<zid>
I'm reading the actual golang dev thread for it
<zid>
which I linked
<clever>
1500 store paths deleted, 735.09 MiB freed
<bslsk05>
virtuallyfun.com: Building OSKit | Fun with virtualization
<Izem>
great news to see stuff like this is possible
<kingoffrance>
that guy......does lots of things :)
<kingoffrance>
it was inevitable, matter of time :)
<Izem>
yeah, great stuff :)
ElectronApps has quit [Read error: Connection reset by peer]
ElectronApps has joined #osdev
srjek has quit [Ping timeout: 256 seconds]
radens has joined #osdev
<radens>
Is there a good document I can cite for the programming interface for a PC UART? I.e. one which authoritatively state that com1 is at port 0x3f8?
<Mutabah>
Well, that's more a convention from the original IBM PC
<Mutabah>
but the chip itself should be well documented
<radens>
Is that written authoritatively anywhere?
<radens>
Like if I want to program a raspi there's a broadcom document I can cite/read
<Mutabah>
The IO address? no
<Mutabah>
Well, it's written in many places
<Mutabah>
and individual chipsets will fully document it
<Mutabah>
but there is no one PC spec that defines the interfaces
<Mutabah>
because they're all maintaining compatability with clones of the IBM
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
GeDaMo has joined #osdev
mcfrdy_ has joined #osdev
vinleod is now known as vdamewood
trufas has quit [Ping timeout: 276 seconds]
trufas has joined #osdev
Izem has quit [Quit: leaving]
dh` has quit [Remote host closed the connection]
radens has quit [Quit: Connection closed for inactivity]
dh` has joined #osdev
MarchHare has quit [Ping timeout: 255 seconds]
vai has quit [Remote host closed the connection]
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
X-Scale has joined #osdev
mcfrdy_ has quit [Quit: Connection closed for inactivity]
pwng has joined #osdev
ElectronApps has quit [Read error: Connection reset by peer]
ElectronApps has joined #osdev
frdy has joined #osdev
nyah has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
mctpyt has quit [Ping timeout: 255 seconds]
SGautam__ has quit [Ping timeout: 252 seconds]
SGautam has joined #osdev
SGautam_ has joined #osdev
SGautam has quit [Ping timeout: 268 seconds]
SGautam__ has joined #osdev
SGautam_ has quit [Ping timeout: 255 seconds]
mctpyt has joined #osdev
dennis95 has joined #osdev
SGautam__ is now known as SGautam
isaacwoods has joined #osdev
Oli has quit [Read error: Connection reset by peer]
aleamb has joined #osdev
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 268 seconds]
X-Scale` is now known as X-Scale
vdamewood has quit [Quit: Life beckons]
<klange>
love when I spend an hour trying to figure out a virtualbox issue thinking I broke something, then boot an Ubuntu guest and it has the same problem
<klange>
so I guess mouse input is just completely broken in the current packaged build of virtualbox on Ubuntu 20.04 :)
<klange>
With integration, no mouse movement is reported unless a button is pressed. Visible in Ubuntu as a lack of hover highlight on GTK buttons.
<zid>
interrupts were broken in my qemu for ages so I gave up
<zid>
I reinstalled the VM recently and they started working, no code changes
<zid>
downgraded qemu and.. they still bloody worked
<zid>
kvm is just haunted
<klange>
Without integration, it seems to be reporting button 1 is down after it's released, visible in Ubuntu guest as not being able to stop dragging a window by its titlebar
<klange>
With integration, right click produces a left click, then see previous issue...
<klange>
zid: kvm does not manage normal interrupts, only fancy newer ones
<zid>
I jsut mean... software that deals with virtualization
<zid>
in general
<zid>
it's too hot to type
<zid>
damnit klange now you've broken my mouse
<zid>
big pauses between update
<klange>
oh super fun that Ubuntu VM was set to use USB tablet, so it's not even some weird PS/2 / hgcm nonsense, it's just straight-up broken
<klange>
qemu has an issue for a long while with PS/2 device buffers being incorrectly intermixed, but it was neatly masked if you used the right scancode set in combination with the vmport mouse
<klange>
the cosmically hilarious thing with that was... I sat down and spent a day doing a bunch of research for a bug report
<klange>
only to have a fix appear in master _an hour before I posted it_.
<klange>
At least I got to confirm the fix...
zid has quit []
<klange>
And yet I'm sitting here still using the version from the 20.04 package repo instead of my git build, so it still has that bug
<klange>
ooh I should test this with a guest that has absolute mouse but _not_ cursor texture support, that would be super obvious
<klange>
maybe tomorrow
Raito_Bezarius has quit [Quit: free()]
Raito_Bezarius has joined #osdev
zid has joined #osdev
<zid>
Hrmph
<zid>
Tried to tab to vmware to make sure it wasn't doing it, dwm completely locked up
<zid>
force logged myself out, logged back in, mouse still janky. Killed a bunch of programs and services, still doing it
<zid>
measured DPC latency, normal
<zid>
turned monitor on and off.. working agan
<zid>
usb hub in my monitor overheating is all I can think
freakazoid333 has quit [Ping timeout: 252 seconds]
aleamb has quit [Ping timeout: 265 seconds]
mctpyt has quit [Ping timeout: 252 seconds]
zoey has joined #osdev
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
Electron has joined #osdev
ElectronApps has quit [Ping timeout: 265 seconds]
myon98 has quit [Quit: Bouncer maintainance...]
mctpyt has joined #osdev
dude12312414 has joined #osdev
myon98 has joined #osdev
nyah has quit [Read error: Connection reset by peer]
gmacd has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
aleamb has joined #osdev
Electron has quit [Remote host closed the connection]
MarchHare has joined #osdev
freakazoid334 has joined #osdev
NieDzejkob has quit [Quit: No Ping reply in 180 seconds.]
NieDzejkob has joined #osdev
SGautam has quit [Ping timeout: 252 seconds]
tacco has joined #osdev
Terlisimo1 has quit [Quit: upgrade time]
tacco has quit [Ping timeout: 258 seconds]
nyah has joined #osdev
tacco has joined #osdev
Terlisimo has joined #osdev
puckipedia has joined #osdev
puck has quit [Ping timeout: 276 seconds]
puckipedia is now known as puck
charco has joined #osdev
<charco>
Hi! I am having some issues running the hello world gnu-efi program. I am following the steps in https://wiki.osdev.org/GNU-EFI but when I run the program from the EFI Shell in QEMU with OVFM I get `command error status: not found`. Any ideas?
<bslsk05>
wiki.osdev.org: GNU-EFI - OSDev Wiki
lucf117 has joined #osdev
pwng has quit [Ping timeout: 268 seconds]
jjuran has quit [Ping timeout: 265 seconds]
* geist
waves
* GeDaMo
particles
* clever
self-interferes
<GeDaMo>
Don't do that in public, you'll get arrested :|
<charco>
Hi geist
<geist>
lo charco, wasn't sure if it was the same one
<charco>
the one and only, trying to learn about UEFI :p
XgF has quit [Remote host closed the connection]
XgF has joined #osdev
<geist>
noice. i haven't looked into the GNU-EFI stff, but i dont think it gets glowing reviews from most folks i know that have fiddled with it
<charco>
I just found what the issue was. At some point it converts a .so to a PE with objcopy, and I typoed the name of a section (reloc instead if .reloc) and that was the cause of the issue.
<charco>
I started using POSIX-UEFI, which seemed easy to use. It worked on QEMU, but I couldn't get it to work on real hardware
<geist>
ah. is this x86?
<charco>
x86-64
<charco>
why?
<geist>
oh just curious
<charco>
Ah, no, no, I am just trying to learn about the UEFI environment. The spec says for example that all memory is identity mapped, but it doesn't specify which protections it has (rw?) so I wanted to create an app and play with that.
dude12312414 has joined #osdev
<geist>
ah. yeah and it's also different per arch. the ARM and riscv addendums to the spec call that out in basically the same way, but since their mmus work differently it isn't exactly the same thing
dennis95 has quit [Quit: Leaving]
GeDaMo has quit [Quit: Leaving.]
<geist>
charco: fun thing you can do if you want to see how uefi sets up the page tables: boot on qemu x86 without KVM, get to the uefi shell and then drop into the qemu monitor and use 'info tlb' and/or 'info mmu'
<geist>
it'll dump the page tables
<geist>
might work on KVM but it'd definitely work if using TCG
mctpyt has quit [Ping timeout: 255 seconds]
<sortie>
I have coffee :)
<charco>
Nice, I just tried it (`info mem`, not mmu). To my surprise it seems to be using 2MiB pages?
<sortie>
Today in osdev: gcc fails to compile, genautomata crashes on null. I'm cross-compiling a i686 gcc using a i686-targeting gcc running on my x86_64 OS, so, uh, quite the fringe case :)
<sortie>
charco, awesome that you're playing with uefi :) I hope you contribute some of your learnings back to the wiki so people after you have good resources :)
<nshp>
charco: fwiw, edkII includes a build system for UEFI applications/drivers with examples
<geist>
charco: yah sure, that makes sense to me
<nshp>
it's the reference implementation that most real implementations are forks of, it's pretty functional and less annoying than gnu-efi as well
<charco>
nshp everywhere in the wiki it says that it's complex and bloated, so I'm trying to avoid it :p
<geist>
you know i was just thinking: one of the reasons the apple M1 based systems seem to not be as picky about memory usage (ie, 16GB doesn't seem tob e a problem) is compressed memory may be so much cheaper there
<geist>
was just looking at the ram usage on this mac mini m1 and it has a huge amoutn of compressed ram in place, very aggressive abouti t
<nshp>
charco: it's complex and bloated, but its application build system isn't
<geist>
but.... when i was reading about the instruction extensions that apple has, someone uncovered that there's literally a 'compress page'/'decompress page' instruction
<nshp>
plus, your hardware almost certainly runs edkII already, so it's not _more_ bloat than you already have :P
<geist>
that plus they're using 16k pages means it'd actually get a fairly good run on compression
<geist>
if those instructions are pretty cheap/fast/free then makes sense that they may tune their vm for aggressive compression
<charco>
M1 has memory compression instructions?! nice
<geist>
yeah i remember noticing this a while back. it's in the extension opcode space, so a valid thing for apple to do and still be an ARM implemenation
<geist>
probably uses some fairly cheesy compression method, but if it's done in hardware then its probaby fast as heck
<charco>
how do they use it? do they compress a bunch of pages instead of paging them out?
<geist>
presumably they compress first and page out later
<geist>
the xnu vm has always been tuned to aggressively use swap, but with cheap compression i can see why that'd change things a bit
<geist>
i had definitely read before that especially on mobile devices the relative energy cost of compression is much lower than reading/writing to flash, even without hardware accellerated compression
<charco>
I see. So they keep a section of ram for compressed memory, and also use that same region for swapping into disk. Android does something like that with zRAM too, but that's just software
gmacd has quit [Remote host closed the connection]
<charco>
hm, this is weird. I set qemu's memory to 64M, but when I do `info tlb` I get everything idd mapped from 0x0 to 0xfffe00000. I was expecting uefi to only map the ranges that were available?
<clever>
thats nearly 64gig!!
<clever>
charco: what does `info mtree` say?
<charco>
`info memory_size_summary` displays 64MiB, I am looking at mtree now
<clever>
charco: i think line 138 is saying that the vga mmio is at ~3088mb into the physical space
<clever>
so if you want to access vga mmio, that also has to be identity mapped
<clever>
and just mapping everything with hugepages, could be simpler then figuring out what to map where
<charco>
I see
<charco>
That makes sense
<clever>
different implementations of uefi may also behave differently
<charco>
When you write an UEFI App are you supposed to call ExitBootServices and then take ownership of the memory mappings? I couldn't find any function to manipulate mappings in the uefi reference so I guess you are not supposed to touch the mappings until after you exit the BS
<clever>
yeah, thats my understanding as well
kwilczynski has joined #osdev
<nshp>
there are plenty of high-level functions for remapping memory
<nshp>
drivers generally have to do it, after all
<nshp>
AllocatePages() in boot services might be what you're after?
<nshp>
(or FreePages())
<charco>
Yeah, I looked at those, but it doesn't do what I want. I want to grab one of the already mapped entries an change the attributes for example
jjuran has joined #osdev
<charco>
So I look at the output of BS->GetMemoryMap and it has a bunch of ranges that are EfiConventionalMemory... According to the spec, those ranges are identity-mapped, but I cannot assume anything about the attrs of the mapping (RO? X?) so before writing to that memory I need to set the right attributes...
<nshp>
I believe it is defined? e.g. EfiBootServicesCode should be RX, EfiBootServicesData should be RW
<nshp>
that said, I don't believe there _are_ any memory protections in reality
<nshp>
not that the spec forbids it or anything, but I've not seen anything actually set protections
<charco>
`info tlb` and `info mem` from qemu show some mappings as NX, and some mappings as RO
<charco>
It's a long story, that takes me back a couple of weeks ago, when I downloaded an ubuntu image and the sha1 hash kept changing every time I checked
<charco>
tl;dr I want to build an uefi app that checks the memory of my computer, not because I need to, but because I want to learn and this is the perfect example
dutch has quit [Quit: WeeChat 3.0.1]
srjek has joined #osdev
dutch has joined #osdev
<sortie>
Well turns out my bug was a well known one where c++ programs crash on startup if they use both pthread_create and anything from libstdc++ (including exception handling implicitly pulled in by operator new), and this bug manifested in a surprising place where these conditions came true only under certain architectures and optimization options
<sortie>
That'll teach me to fix these bugs instead of sweeping them under the rug so they pop up and surprises me nastily like this
<sortie>
Woohoo I managed to cross-compile my 32-bit OS build in its entirety from my 64-bit OS build.
<Izem>
nice
<sortie>
This makes it easier to do the next stable release when I just need one self-hosting installation to build both archs, rather than two installations and splicing the built release directories together
<Izem>
which one is going to be self hosting, the 64 bit one?
wereii has joined #osdev
<sortie>
Izem, yeah I usually prefer the 64-bit build
<sortie>
The 32-bit build has a super rare double fault kernel panic for that reason.. only found when doing the full self-hosting build on it. So that's also part of why I build the 32-bit release under 64-bit, cuz' the other way doesn't work yet
<clever>
sortie: any focus on reproducible builds?
<clever>
if 32bit and 64bit hosts generate the exact same binary, then you know you dont need to test the differences
Izem has left #osdev [Konversation terminated!]
<sortie>
clever, excellent question. Unfortunately not yet :) But reproducible builds is absolutely something I want to explore
<sortie>
I do know, however, that the cross-compiling my OS's ports tree vs. compiling it natively, results in a different set of files being installed
<sortie>
I'd likely see some of those differences
<sortie>
Plus many differences can leak into reproducible builds.. like I saw differences because sort(1) on my OS vs. grep gave a slightly different order for strings that otherwise compared equal