<bslsk05>
ftp.gnu.org: Using as - 80386 Dependent Features
Beato has quit [Quit: I have been discovered!]
Beato has joined #osdev
demindiro has quit [Quit: Client closed]
demindiro has joined #osdev
demindiro has quit [Quit: Client closed]
heat has quit [Ping timeout: 248 seconds]
genpaku has quit [Remote host closed the connection]
genpaku has joined #osdev
avarai has joined #osdev
<epony>
"I'm debugging my own debugger with my own debugger and it looks like there is a bug in the other debugger that I am using to debug my own debugger." --W.T.F.^Z
<heat>
actually that explains the lack of new features in android 13, they were too busy rewriting everything in rust
<heat>
nullpointerexception bad, unwrap perfect
<heat>
that reminds me I do need to fix my rust port
<heat>
i'd like to play around with rust in my OS but I don't want to make llvm a dependency for gcc builds :/
<j`ey>
gcc suppoprts rust now!
<mjg>
rust onyx rewrite when
<Ermine>
heat: ST
<Ermine>
heat: I've got my android 13 update recently, and now it asks me to reboot it so it can clean up
<Ermine>
Also, samsung ui for sleep mode became cringy
<Ermine>
Also, samsung still ships some borked Wi-Fi implementation
torresjrjr has quit [Ping timeout: 260 seconds]
torresjrjr has joined #osdev
<kaichiuchi>
just use an iphone like I do
* kaichiuchi
holds up the umbrella
<kaichiuchi>
i don’t want to start a war but I think some of apple went downhill after jobs died
<kaichiuchi>
woz used to come on freenode at one point
<heat>
Ermine, hm? why do you say the wifi is borked?
<heat>
also what's the problem with sleep mode?
<Ermine>
heat: it fails to connect to my home AP in some situations. Other devices do not have such issues afaik
<heat>
i've had issues connecting to my 5ghz router but the router is also super borked so I don't know whose fault it is
epony has quit [Ping timeout: 268 seconds]
<kaichiuchi>
i hate my router.
<heat>
same
<snowcra5h>
your router hates you
<heat>
j`ey, i thought it couldn't even compile the core crate?
<heat>
i'm no expert but that sounds like it isn't ready lol
<snowcra5h>
kaichiuchi: woz actually was on freenode ?
<j`ey>
heat: probably what was merged into gcc wasnt much
<kaichiuchi>
snowcra5h: for 68k stuff yes
<snowcra5h>
Very cool
<snowcra5h>
also <3 68k
<Ermine>
I tried OpenWRT and there still were some issues with my phone afair
<snowcra5h>
For our assembly class in University we learned m68k and wrote a game for the Atari.
<snowcra5h>
replaced the operating system TOS
<snowcra5h>
it was really fun actually.
<heat>
j`ey, using the rustc gcc backend would probably be a better idea but I don't know how far along that i
<heat>
s
<j`ey>
I guess that's much further along
<sham1>
68k was such a good processor. Hell, I feel that in terms of design it could give even more modern offerings a run for their money
<kaichiuchi>
people still use it today
<snowcra5h>
Yeah they do.
<kaichiuchi>
hell some people still use the 386
<sham1>
Yes, in embedded
<kaichiuchi>
people still use Z80s
<heat>
VAX best architecture
<heat>
because of... i dont know, UNIX?
<heat>
oh and AT&T syntax
<snowcra5h>
I like AT&T syntax
<snowcra5h>
more than intel
<sham1>
Heresy
<kaichiuchi>
indeed
<sham1>
You use whatever syntax goes with your processor, god damn it1
<snowcra5h>
lol
<kaichiuchi>
in our products we use STM32F446
<snowcra5h>
Good old arm
<heat>
in my product I use the hitachi magic wand
<heat>
go figure
<kaichiuchi>
the test engineers are still playing with my clang build
<kaichiuchi>
they found two issues but fairly minor
<kaichiuchi>
that’s one small step for man, one giant leap for LLVM
<snowcra5h>
rofl
<sham1>
heat: ( ͡° ͜ʖ ͡°)
<snowcra5h>
What do you do for work kaichiuchi ?
<kaichiuchi>
ever been to a vending machine and put physical money in it? that particular equipment
<snowcra5h>
Very cool.
<kaichiuchi>
but before I was a test engineer for die bonding machines
<heat>
can you add a free money glitch
<heat>
thank
<kaichiuchi>
worst job i’ve ever had
<snowcra5h>
haha
<snowcra5h>
well you have a damn cool job now
<snowcra5h>
heat: lol
<kaichiuchi>
heat: you don’t want to know man.
<kaichiuchi>
heat: ok
<kaichiuchi>
wtf is going on with irccloud
<snowcra5h>
wtf is irccloud
<heat>
irc on the cloud
<snowcra5h>
like a shell with BitchX on it ?
<kaichiuchi>
there’s a lot of wacky shit we do
<kaichiuchi>
at work
<kaichiuchi>
I would kill to try and redo this in C++ but I think I’d get shot
<heat>
I would shoot you
<snowcra5h>
I would load the gun
<snowcra5h>
C is bliss.
<heat>
if you tried to rewrite it in rust I would cut your genitals out and feed them to your dog
<snowcra5h>
lol
<mjg>
snowcra5h: heat is a fetishist
<heat>
if you tried to write something in C I would cut your genitals out and feed them to your cat
<mjg>
that's how he flirts
<heat>
tldr don't write anything in languages
<heat>
use java
<mjg>
use php
<snowcra5h>
lol
* kof123
waits for john wick language to revenge heat
<kaichiuchi>
you’re in game developer territory
<snowcra5h>
java is a nice language some times
<kaichiuchi>
god..
<snowcra5h>
everything should just be written in c though
<kaichiuchi>
okay since irccloud sucks
<snowcra5h>
keep it simple
<heat>
3 billion devices run java, why shouldn't you build your stuff on it
<kaichiuchi>
there’s a lot of things that C++ would make a little easier for us
<kaichiuchi>
HOWEVER
<snowcra5h>
java is the bell curve
<snowcra5h>
haha
<kaichiuchi>
a) we compile with -O0
<sham1>
As someone who writes Java at $JOB, how about no
<heat>
snowcra5h, the scenes when keeping it simple doesn't work
<kaichiuchi>
try doing modern C++ with -O0 when you realize the fancy template magic can’t be used
<snowcra5h>
I don't actually mind C++
<sham1>
C++ is the epitome of "sufficiently smart compiler" being a requirement
<snowcra5h>
Java is a nice language as well to be honest
<snowcra5h>
lol
<kaichiuchi>
i’ve never used java
<kaichiuchi>
never want to
<heat>
the scenes when you write shitty C with no out of bounds checks and no sanitizers so your memory management is loosey goosey and then you reinvent reference counts
<sham1>
Ew, refcounts
<snowcra5h>
kaichiuchi: you just try catch everything
<heat>
sham1 only uses RCU exclusively
<kaichiuchi>
yeah I don’t like exceptions
<kaichiuchi>
never have
<snowcra5h>
and threads are magic
<snowcra5h>
semaphores
<snowcra5h>
wrap everything
<snowcra5h>
haha
<snowcra5h>
I met James Gosling IRL
<kaichiuchi>
I don’t particularly like java because it’s basically FACTORYGENERATOR NEW FILEREADER NEW STRING NEW HEAT NEW RUST
<snowcra5h>
yeah
<heat>
i bet you wish you had met ryan gosling
<snowcra5h>
I thought it was ryan gosling
<snowcra5h>
that's why i went
<sham1>
Meh, at least now it's a bit shorter because there is finally local type inference
<kaichiuchi>
even if it wasn’t for that
<kaichiuchi>
the resources it uses is simply untenable
<snowcra5h>
well good chat im going to get some work done
<kaichiuchi>
from a performance perspective i’ve rarely seen fast java stuff
<snowcra5h>
thats not always that true
<kaichiuchi>
it exists but you have to really work at it
<snowcra5h>
we used java in our datastructures and algorithms class
<snowcra5h>
it wasnt really slow
<snowcra5h>
Just dont write bad code
<kaichiuchi>
robert sedgwick’s algorithms textbooks use java and I hate it
<snowcra5h>
haha yeah
<sham1>
Java is fast after a while. The problem with benchmarks is that they're not representative of proper workloads
<snowcra5h>
^^
<kaichiuchi>
“after a while” is what sucks
<kaichiuchi>
never mind the fact it uses 7464674747 MBs of RAM
<kaichiuchi>
one Java product that I refuse to give up, and you’d have to pry it from my cold dead hands is CLion
<kaichiuchi>
but god, the memory usage
<snowcra5h>
total used free shared buff/cache available
<kaichiuchi>
intellij’s products have always been good to me
<snowcra5h>
Yeah they are a really good company
<snowcra5h>
Id rather just use vim or emacs though
<kaichiuchi>
but I would never in a million years write Java
<snowcra5h>
the CAFEBABES will be sad =\
<sham1>
Consider yourself lucky. I do legacy Java
<snowcra5h>
That's actually pretty cool.
<kaichiuchi>
yeah i’d rather my cock would just fall off and i’d get fired so i wouldn’t have to deal with that
<snowcra5h>
ROFL
<kaichiuchi>
at my previous job, the code is essentially 20-30 years old still using MFC and insane crazy horrifically bad C++
<kaichiuchi>
no one knew how it compiled or even worked
<kaichiuchi>
it just did and we rolled with it
<kaichiuchi>
it was upsetting
<kaichiuchi>
when all of the old guys retire (who are not useful for their coding, but for “what does the machine do here” since nothing was ever written down), they are going to have a problem
<kaichiuchi>
because it would take a separate team months to learn how anything works
<kaichiuchi>
the inheritance depth is something like 25 classes in the worst case
<kaichiuchi>
A inherits B, B inherits C, C inherits D, … up to 25
<kaichiuchi>
and of course when you’d run the software in debug mode it quite literally took over 30 minutes to start
<sham1>
I've had to read code like that from outside. Not fun
<kaichiuchi>
it’s one of the worst examples of software engineering i’ve ever seen
<kaichiuchi>
and the “solutions” people have come up with are substantially worse
<kaichiuchi>
jamie zawinski forgive me but I’d start the software from scratch
<kaichiuchi>
all of the testing that is supposed to be for a machine accurate to a speck of dust is done manually
<kaichiuchi>
the same bugs pop up every new release
<kaichiuchi>
they’ve shipped with known showstoppers because they can’t piss off their customer
<kaichiuchi>
there was nothing to learn or gain from there in any way, and my new job which is 30 minutes away from that place told me some stories about them that I had no idea
<kaichiuchi>
so it wasn’t just me
<kaichiuchi>
it was “jesus fuck how is anything even working and how are any of us still alive when it’s nothing but a bag of strings and pulleys”
epony has joined #osdev
<kaichiuchi>
i dunno, I could rant all day about it because that type of incompetence at that level of precision is nothing but god laughing uncontrollably
<kaichiuchi>
and if that happens there, what do you think goes on under the hood with medical devices?
<bslsk05>
en.m.wikipedia.org: Therac-25 - Wikipedia
<kaichiuchi>
you get blasted with a lethal dose of radiation running out of the treatment room saying you’re on fire
<kaichiuchi>
all because the proper controls weren’t in place
<kaichiuchi>
ok i’m done you may all speak freely
<heat>
kaichiuchi, > CLion
<heat>
man, I use vscode
<kaichiuchi>
in both cases the underlying software is awful
<kaichiuchi>
electron vs java pick your poison
<kaichiuchi>
600MBs for a text editor
<heat>
i'm pretty happy with vscode all things considered
<kaichiuchi>
suck it
<kaichiuchi>
and by “suck it” i mean “who thought web browsers masquerading as native apps” were a good idea?
gog has quit [Read error: Connection reset by peer]
<kaichiuchi>
20 years ago you would’ve been laughed off the stage
<kaichiuchi>
because, surprise, web browsers do a billion things that you can’t control
<kaichiuchi>
and all of them are inefficient for what Discord is, for example
<kaichiuchi>
chrome, discord, and CLion are by FAR 99% of my memory usage
gog has joined #osdev
<kaichiuchi>
unfortunately though, they work
xenos1984 has quit [Ping timeout: 260 seconds]
xenos1984 has joined #osdev
avarai has joined #osdev
<heat>
kaichiuchi, but discord sucks and is poorly programmed
<heat>
just for the sheer fact that it gratuituously burns CPU even when idle
<kaichiuchi>
i don’t believe it would make a difference if it was the best electron app ever devised
<kaichiuchi>
it would still be electron
<heat>
vscode burns less cpu then discord
<kaichiuchi>
yes, I agree
<mrvn>
heat: is that discord doing or just the browser. because the browser still does that even without discord
<heat>
the browser does not do that, see vscode
<mrvn>
heat: firefox does a sync() every 10s always
<mrvn>
focus, no focus, not exposed, minimized, always.
<heat>
certainly not a sync
<heat>
that would be very noticeable
<heat>
at most, an fsync()
<gog>
let that sync() in
<zid>
discord still dealing with the 40 goat gifs you're getting sent per second heat
<mrvn>
sorry, yes, fsync. and it is noticeable
<zid>
decoding them all to vram so it can pew them to screen
<heat>
zid, the goatse previews don't render themselves
<kaichiuchi>
a part of me doesn’t understand why browsers use so much RAM to begin with
<heat>
aw that's easy
<kaichiuchi>
no it isn’t
<heat>
1) you're emulating a full operating system 2) you have like 5 or 10 different interpreters 3) a full interpreter + bytecode VM + jitter 4) a bunch of isolation stuff 5) a full renderer conforming to the 10000000000000000 web specs
<zid>
20MB of javascript source and 200MB of uncompressed images per page
<heat>
^^all of the above needs to be safe and fast btw
<zid>
plus it's all so slow you need a cached copy of everything in the current and previous page
<zid>
s
<zid>
your back button doesn't do a web request
<heat>
good point, you also do caching in RAM
<zid>
yea IE5's strat of writing shit to disk as cache is just.. a non-option when internet is 100x as fast as rust
<heat>
RUST?
<heat>
POGGERS
<zid>
we have pagefiles for *precisely* that anyway
<mrvn>
zid: bullshit. back button is mostly useless because everything is web 2.0+
<zid>
everything is 100x as fast as rust
<mrvn>
zid: +caching
<zid>
Anyway, a browser is routinely the largest and most complex interative software I use
<heat>
zid, they do write stuff to disk, but they keep a copy in RAM sometimes
<kaichiuchi>
it also doesn’t help that you can write horrible invalid HTML and it will still work albeit with flaws
<zid>
even on a 'simple' webpage
<heat>
with an LRU thing or whatever
<zid>
I'd expect a desktop PC program doing similar stuff to use a few hundred MB
<kaichiuchi>
so the browsers are guessing
<heat>
kaichiuchi, oh yeah, forgot the infinite compatibility problem
<zid>
like, loading front page of reddit is often a few /hundred/ images and web requests
<zid>
the web requests all do cookies etc in their headers, those need 32kB buffers each
<zid>
the images themselves need the image file + the decompressed rgb
<heat>
I think browsers serialize HTTP1.1 connections per subdomain
<zid>
if the thumbs are on reddit, you can re-use yea
<zid>
http keep-alive
<mrvn>
zid: do they? you could decode imasges as they become visible (plus a bit of margin)
<kaichiuchi>
i dunno.
<heat>
HTTP2 IIRC usually is able to handle a bunch of concurrent connections
<heat>
QUIC has even more concurrency (IIRC) and better performance
<kaichiuchi>
at work chrome is using 870MB
<zid>
okay so nothing
<zid>
have you seen the size of my framebuffer
<mrvn>
heat: http1.1 has keep-alive and pipeline. They only thing new in 2.0 is that you can interleave data of replies.
<mrvn>
heat: out of order replies
<kaichiuchi>
teams is using 200MB
<zid>
That's like, half a second of fps video :P
<heat>
something I have noticed is that the browsers seem to scale their memory usage based on how much RAM you have
<zid>
60*
<kaichiuchi>
no it’s not nothing
<zid>
Yea it really is
<kaichiuchi>
when you start to think nearly 1GB of RAM usage is nothing, problems emerge
<mrvn>
kaichiuchi: and then you try running kvm --mem 64
<kaichiuchi>
what’s the upper bound where you start to be concerned?
<zid>
1.5MB of that is *just* the minified javascript of the page you're on
<gog>
depends on if it's real or VM
<kaichiuchi>
when you’re thrashing the ever living shit out of your swap?
<zid>
80MB+ of that is prorgram image
<mats2>
teams always sucks
<mrvn>
kaichiuchi: I've no swap. :)
<zid>
that they only need 700MB to deal with several meg of javascript and images is insane
<kaichiuchi>
how much RAM do you have
<gog>
16GB
<mrvn>
kaichiuchi: 64GB
<zid>
32 gigglebytes
<kaichiuchi>
yeah then you’re fine
<zid>
well yea, my machine is from 2011
<zid>
I'd hope it's fine
<kaichiuchi>
but me, a peasant with 16GB
<mrvn>
I'm fine with 2GB too. If you need to actively swap (as in swap in stuff) your system is effectively dead.
<zid>
16GB is also totally fine to burn 870MB on a web browser on
<kaichiuchi>
i routinely run out of RAM with just a handful of programs open
<zid>
I was on1 6GB until recently
<heat>
I have 8GB
<heat>
it still works
<mats2>
maxed out specs on a current gen x1 carbon and a teams video call lags with just outlook open
<zid>
Scaleform GFx allows licensees to create user interfaces using Adobe Flash authoring tools, such as Adobe Flash Professional; the resulting SWF files can be used directly by the GFx libraries, providing similar functionality to the Adobe Flash Player but optimized for use within game engines.
<heat>
what do you think develops csgo, not-valve?
<zid>
heat: I went through 4 personally
<zid>
I assume 3 more is about right given the timescale
<kaichiuchi>
jesus christ
<heat>
how 4?
<kaichiuchi>
that’s sad
<zid>
flash is kinda.. exactlyt he right tech for it though
<heat>
in terms of technology they switched once, in terms of look they switched like, 3 times
<zid>
it's interactive enough that we played *games* on it for years, and it's all svg based
<bslsk05>
'CS:GO's Panorama UI VS Older Versions' by 3kliksphilip (00:14:34)
<sham1>
C99+ or riot
<heat>
panorama is the only non-scaleform one
<Ermine>
heat: it definitely isn't
<heat>
Ermine, did the older ones not use scaleform?
<kaichiuchi>
for new projects I have no idea why you’d want to use C89
<kaichiuchi>
unless you must be compatible with an ancient compiler
<zid>
It's flawless
<Ermine>
heat: I meant c89
<heat>
oh right lol
<heat>
absolutely
<kaichiuchi>
zid: you’re me, but a serious me
<heat>
c89 best language ever
<zid>
go ship something in rust, 3 days later it'll stop compiling due to a nightly change
<heat>
it still reeks of shitty compiler
<heat>
zid, that's on you for using nightly
<kaichiuchi>
me: i love retro stuff, I want to experiment and make something work on retro stuff
<zid>
My C89 still builds and is still faster than anything else
<zid>
so what would I change to? Something that will break, and be slower?
<zid>
Okay.jpg
<kaichiuchi>
you: i want to live in the 80s, i really mean it
<heat>
ok but srsly, in modern terms C89 really sucks
<kaichiuchi>
yes of course it does
<sham1>
Doesn't even have constant-width integers
<sham1>
A must-have for embedded and osdev
<heat>
the standard library is super lackluster, it still has all the decl-code crazyness, no constant-width shit, no atomics, no defined memory model, no threads
<heat>
still has gets!!
<sham1>
IIRC gets was already deprecated in C89. At least in C99, and C11 just removed it wholesale
<zid>
You know what else sucks? literally everything else
<Ermine>
I use skalibs instead of standard library stuff when applicable.
<kaichiuchi>
C99 is just fine
<zid>
but now you have lots of fun issues like: -Og is too slow to be usable (hi C++), it's impossible to package (hi python), etc, etc, etc
danilogondolfo has joined #osdev
<zid>
C89 is the lowest common denominator and *still* better
<kaichiuchi>
yeah I have to agree with the C++ comment
<heat>
erm what?
<heat>
Og works fine
<zid>
it was his rant from the other day
<kaichiuchi>
only on gcc if you’re lucky
<Ermine>
what about gOg?
<zid>
std::move is a mess of templates that Og doesn't compile well
<zid>
or something
<heat>
which is O0
<kaichiuchi>
not anymore
<kaichiuchi>
clang fixed that
<sham1>
I'd still rather C99 than C89. C89 is fine enough, but I'd rather C99. Well really I'd C2023, but that's not a thing yet
<zid>
Og is not O0 in theory it's just "don't do annoying optimizations that remove vars"
<heat>
python is literally the easiest to package, see pip
<heat>
the problem was with O0
<heat>
not Og
<heat>
Og works
<zid>
sham1: I do use C99 if I see a good use for it, mainly designated initializers
<kaichiuchi>
game developers often use MSVC
<heat>
(clang actually doesn't have Og, they just pretend it does)
<zid>
so that I don't have to do 0,0,0,0,0,0,0,0, /* 8 */ 0,0,0,0,0,0,0,0, /* 16 */
<zid>
I can just do [38] = 3
<kaichiuchi>
yeah it’s -O1 on clang
<zid>
I use C11 on super rare occasions for anonymous unions
<zid>
C23 I can't imagine using anything from, yet
<heat>
C23 has portable time
<kaichiuchi>
debug performance with C++ is a problem if and only if you’re under serious time constraints (like games) or you have space issues
<zid>
maybe something will catch my interest
<sham1>
Designated initializers are good
<zid>
I don't use time
<sham1>
C23 has binary literals, which has been a long time coming
<zid>
sham1: also compound literals
<sham1>
Also, C23 apparently might have stuff for macros, like __VA_OPT__ to handle variadic macros in a nice manner
<sham1>
Also typeof, so we can get one step closer to standards-compliant container_of
<kaichiuchi>
what’s that do over __VA_ARGS__?
<zid>
what is that weird unicode you keep typing
<sham1>
__VA_OPT__ is a functional macro that expands to its argument iff the variadic argument was passed
<bslsk05>
en.wikipedia.org: One red paperclip - Wikipedia
<GeDaMo>
"traded his way from a single red paperclip to a house"
xenos1984 has quit [Ping timeout: 260 seconds]
<kaichiuchi>
that’s pretty neat
<epony>
that's what skyscrapers are built with: paper clips.. their only weakness, paper planes
<gog>
what about paper jet fuel
<mrvn>
"On or about January 7, 2006, he traded the second spot on the Yahk trip for a box truck." So what hapened to the first spot?
<mrvn>
He should have used a green paper clip, much bigger house.
<Ermine>
heat: to reiterate about EFI a little: is it hard to do EFI without posix-efi/gnu-efi? IIUC I need to hardcode some table adresses and make some frapper functions and instruct linker to do the right thing.
<Ermine>
Assuming that I'm going to use clang
<zid>
I'm tempted t make an uefi binary
<zid>
using --output-format=binary and lots of .dword
<zid>
like I do for gameboy and playstation and stuff
<Ermine>
and maybe specifying entry point
<zid>
entry point not required, it's in a field in the PE header
<zid>
so it'll just be .dword _start somewhere
<zid>
(same for all object formats, really)
<Ermine>
But I guess this _start part should be written in assembly (and call C entry point)
<mrvn>
Ermine: has to be, you have to at least set the stack pointer
<mrvn>
Ermine: zeroing .bss from C is tricky but possible
<Ermine>
fair enough
<zid>
yea unless EFI gives you a valid C environment to begin with? it might idk
<mrvn>
so usually you do set the stack and zero .bss in asm and then jump to C.
<gog>
it does
<zid>
_start for sysv for example needs to convert between stack and registers for main's args
<Ermine>
I need to read spec for this :D
<zid>
and someone needs to zero all your `static`s
<zid>
either the host or _start
<gog>
when the firmware loads your image on x64 you have at least 64KiB of stack
<mrvn>
gog: does EFI even call _start?
<gog>
it reads the PE for the entry point
<zid>
does eif main take args? are they set up as per the C abi?
<gog>
it's ms_abi
<zid>
means nothing to me
<zid>
C and sysv ABIs are different, as above, so _start has work to do
<zid>
you can't make main() your entry point
<zid>
efi land is fully unknown to me
<gog>
efi entry point wants two args, EFI_HANDLE in rdx and EFI_SYSTEM_TABLE in uhhh
<gog>
i can't remember
xenos1984 has joined #osdev
<gog>
whichever the second param goes into in x64 msabi
<gog>
or is it rsi rdx
<gog>
whatever
<zid>
right but all that matters is whether it matches or not
<zid>
not specifically what it is
<gog>
gnu-efi has a _start and it's the entry point and it'll convert from msabi to sysv
<zid>
right I'd have the same issue eh, cus I'd be using stock gcc and .asm header files for the PE stuff
<gog>
but it doesn't match, msabi is rcx and rdx, sysv is rdi and rsi
Ram-Z has quit [Ping timeout: 260 seconds]
<sham1>
Of course GNU would turn to its preferred calling convo
<zid>
right but sysv doesn't even match *itself*
<zid>
I don't know if you can do msabi main and have it replace start
<zid>
sysv has entirely different calling convention for _start and C
<Ermine>
gnu-efi has uefi_call_wrapper function
<gog>
it's not strictly necessary
<Ermine>
I guess it is for calling convention stuff
<zid>
calling convention stuff catches me out on windows all the time
<gog>
if your compiler isn't trash you can just declare anything that needs to be called by the firmware as EFIAPI
<zid>
I constantly forget to mark my opengl functions as cdecl or whatever
<zid>
normal imports are fastcall, dll imports are cdecl, or something
<gog>
everything else can be cdecl
<Ermine>
gog: I'm going to use cross clang
<gog>
i recommend that path
Ram-Z has joined #osdev
<gog>
although
<zid>
I don't even know how to boot an efi program
<zid>
I've literally never used it
<gog>
debugging is easier with gnu-efi and qemu
<gog>
because you can just use gdb
<gog>
clang wont' generate dwarf symbols in PE mode
<gog>
afaik
<zid>
you could splitdebug it?
<gog>
it does generate pdb symbols
<gog>
but i didn't dig too deep on how to use them
<gog>
or if it's even possible
<zid>
I splitdebug on playstation
<zid>
as there's no point putting the debug symbols inside the .exe
<Ermine>
So time for WinDbg?
<gog>
it doesn't even generate dwarf symbols though
<gog>
it generates a split pdb
<zid>
(I compile twice)
<gog>
gross
<zid>
And by 'compile twice' I mean 'objcopy -j.text debug.elf out.exe'
<gog>
yeah that's how i did it when i was using gnu-efi
<zid>
that's the outer ELF with dwarf symbols, dump the .text to get the inner EXE
<zid>
without them
<zid>
`file` the ELF in gdb so it loads the symbols
<zid>
connect to the running exe
<gog>
yes
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<Ermine>
Ok, thank you people! <3
<gog>
:3
<sham1>
E:
dude12312414 has joined #osdev
demindiro has quit [Quit: Client closed]
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
<mats2>
adorbs
FreeFull has joined #osdev
<heat>
Ermine, hi, EFI CEO here
<heat>
kinda hard, kinda not hard
<heat>
with clang being able to make PEs natively, it's ezpz
<heat>
if you had to objcopy it becomes a lot worse as you either need a thunk to relocate yourself (gnu-efi route) or translate relocations to PE (edk2 method)
<clever>
heat: what about using a cross-gcc, similar to the mingw32 one?
<clever>
gcc can clearly create x84(-64) PE executables
<clever>
its just a matter of having a build of gcc that is both PE and baremetal
<clever>
and has the right ABI
<clever>
the lack of recommendations for that seems weird
<mrvn>
clever: wasn't the issue about including DWARF infos in the binary?
<clever>
what with baremetal .bin and .elf kernel guides, always stressing the fact that you need the right cross-compiler, and to not use a gcc expecting a libc
<clever>
and then efi guides just abusing objcopy to mutate the build product
<clever>
mrvn: ah, about a lack of debug info in pe files?
<mrvn>
clever: you can use a hosted gcc if you specify all the right flags to turn that hosted gcc into a freestanding one. But forget any one of a number of flags and you get funny results, errors and warnings. So for begginers it's best to give them a fresstanding compiler that can't have those troubles.
<mrvn>
(just FYI)
<clever>
yep
<clever>
and it seems like using the wrong gcc, and then forcing it with objcopy or a relocation thunk, seems just as error prone?
<mrvn>
the only reason you should use objcopy is to turn your 64bit kernel into a 32bit file for x86 multiboot and to turn your ELF into a BIN for embedded / ARM systems that don't like ELF.
<clever>
yeah, those options seem viable
<mrvn>
if you want to relocate then why not use the linker (via the compiler preferably)
<clever>
but abusing it to turn an elf into a pe, just seems like a recipe for problems
<mrvn>
I bet there are lots of ELF features PE doesn't have and vice versa.
<heat>
clever, sure, you can do that, but clang is much handier
<clever>
more so, because clang is multi-target at runtime?
<mrvn>
e.g. do the relocation types even match?
<heat>
yes
<heat>
who tf has a mingw toolchain? not many people
<mrvn>
By the way: Why do you have an objcopy tht creates PE but no compiler?
<heat>
clang can compile your elf kernel, and your PE EFI bootloader, etc
<heat>
because ld can have multiple target emuls
<heat>
gcc can0t
<heat>
't
<mrvn>
You are supposed to build a cross-binutils and not use binutils-multiarch.
<clever>
and clang/llvm just never had that limitation?
<heat>
every clang can build for $ENABLED_ARCHITECTURES for every target it supports, every lld can link every file format
<mrvn>
so you have already left the supported path. go and enjoy the wilderness.
<heat>
mrvn, ah yes, 2 cross-toolchains
<mrvn>
heat: yep.
<zid>
why not six!?
<clever>
heat: so just enable all arches, and you have a silver bullet that can do anything!
<heat>
what's "the supported path"?
<heat>
clever, yup. pretty much. the only problem you'll have is that you'll need to compile your runtimes for the targets
<heat>
but that's doable
<mrvn>
zid: x86, x86_64, x86_32, mips, mipsel, mips64, mipsel64, arm, aarch64, aarch64_32 or whatever the X32 one is called on ARM
<clever>
ive had similar problems with gcc before
<clever>
libgcc was built for armv7 in arm mode, but not thumb mode
danilogondolfo has quit [Remote host closed the connection]
<heat>
if I enable X86 on my clang, it can build x86_64-onyx, x86_64-linux-gnu, x86_64-fuchsia, etc
<clever>
so while gcc and ld where happily generating thumb code for me
<clever>
it linked an arm only libgcc
<clever>
and then faulted at runtime
<mrvn>
zid: add to that ARMv5/6 softfloat, ARMv6 hardfloat, ARMv7 neon
<mrvn>
zid: you easily can end up with 20 gcc or more.
<raggi>
gcc makes you cross
<clever>
mrvn: at least for the entire arm32 family (soft/hard, thumb/arm), it seems to be under the multi-lib flag
<clever>
where you have a dozen libgcc's, and the linker picks the best one for the current flags
<clever>
and gcc can do all combinations
<heat>
I find it kind of silly how llvm doesn't pull some crazy stuff with llvm bytecode and compiler_rt
<mrvn>
How much of the gcc cross madness is rooted in the build system and backend? The frontend is always the same right? The middle end should be identical too, right? Just the codegen and file format part differs?
<heat>
the frontend is not always the same
<raggi>
it's the linux tradition. build on the same machine you install onto.
<mrvn>
clever: but try setting up some multilib config for your needs. It's an absolute nightmare to configure.
<heat>
every target can customize the frontend and add extra flags, etc
<heat>
some targets default PIE for instance
<heat>
(or link extra libraries, etc)
<mrvn>
heat: sure. But that doesn't really change anything how g++ parses c++ source into the intermediate format
<mrvn>
basically just passes those options to the backend
<clever>
mrvn: checking an old PR i never finished, it was just --with-multilib-list=rmprofile when building gcc
<heat>
gcc itself is an absolute nightmare to configure
<heat>
it's all just a bunch of gcc-foo that people just copy around
<heat>
shell script switchs that include other files and those files do things and then they're all included for a target and shit
<heat>
madness
<heat>
llvm has the opposite problem, ez to configure as a target developer, completely maddening to build as a user
<mrvn>
heat: don't forget M4 mactos
<mrvn>
macros
<clever>
the only time ive needed a configure step, was when targeting windows+mac+linux
<clever>
any time i target only linux, ive been able to build purely with just make and nothing else
<heat>
i can't stress enough how hard it is to figure out how to build a fucking LLVM toolchain
<heat>
I basically stole fuchsia's stuff
<clever>
ive even got one makefile+library that can build for 3 different scenarios, baremetal arm, linux arm, and baremetal vpu
<mrvn>
clever: yeah, building clang is easy, my problem is my kernel doesn't support using clang.
<clever>
and it can do MMIO in all of them
<heat>
I don't have enough years to live to figure that out all on my own
<clever>
heat: i still have yet to look into the vpu llvm fork
<heat>
oh and you also need to write non-trivial amounts of C++ for your toolchain, much of which is just bespoke shit that you need
<heat>
so you....... END UP COPYING THINGS
* heat
sighs
<heat>
i hate everything
<heat>
also half my fights with GNU software is fighting with libtool
<heat>
fuck libtool
<clever>
i'm a bit rusty, does llvm-ir have a set number of registers, or infinite virtual registers?
<clever>
does the IR->native step involve register allocation and dealing with spill-over into the stack?
<mrvn>
well, rust is the future. well done.
<sham1>
Rust is the future. Libtool is the past
<clever>
> What makes LLVM so compelling is it lets us write our assembly-like IR as if we had an infinite number of CPU registers and abstracts away the register allocation and instruction selection.
<heat>
libtool will never leave us
<clever>
ah, this blog i read before answers my Q
<heat>
i'll be 97 in my nursing home waiting for my grandchildren to call me and libtool will still be a fucking thing
<zid>
that has a name but I forget what it is
<mrvn>
clever: and yet the compiler then turns that into a stack machine with no register and then eliminates memory (stack) operations by turning that back into real registers.
<mrvn>
WTF?
<clever>
heat: what does libtool even do?
<heat>
clever, link and compile things
<clever>
thats what ld and gcc are for! lol
<heat>
libtool supposedly helps
<clever>
mrvn: lol
<clever>
mrvn: do all llvm backends do that, or just some?
<heat>
it also creates a bunch of parasite .la files that don't support sysroots for some reason
<mrvn>
clever: don't ask me.
<heat>
it is, of course, copied around the autotools projects
<heat>
with an inconsistent path and format (sometimes an m4, other times a shell script)
<heat>
I need to hack it open to tell it that yes, my system supports shared libraries
<raggi>
libtool does hardly anything, it just attempts to hide shitty loader configs and shitty linker configs behind a facade that pretends loading and linking aren't a total disaster in the linux ecosystem
<raggi>
if it ceased to exist, things would improve fast
<mrvn>
and decades old systems that have tiny limits
<raggi>
right "a pile of things you probably don't care about"
<mrvn>
A lot of GNU problems would go away if you throw out legacy stuff
<mrvn>
At some point you just have to stop caring.
<raggi>
there is part of me that appreciates "portability" in the old sense of "keep all the dead shit alive", but there's another part of me that has _tried to use this stuff_ with old machines and seeing that it's all rotting, meanwhile debugging 10kloc more m4 all the time makes me rage
<heat>
it wouldn't be so bad if this was all centralized
<raggi>
the archives of it should probably stick around somewhere, we can use those for building old targets
<heat>
and not copied around
<raggi>
but for building new targets, don't want anymore
[itchyjunk] has joined #osdev
<heat>
GNU making autotools a glorified shell script generated by shell scripts using like two meta-languages was the most horrific mistake they made
<mrvn>
raggi: it's still designed for systems where you don't have autotools. So the autotools generated files have to be included.
<epony>
m4 is about half of m8
<heat>
I say this often, but I really like meson
bauen1 has joined #osdev
<heat>
the language is clean and makes sense, if you want cross-compilation you just use a simple spec file, the interpreter is centralized and if you need to patch things you can just patch them once
<bslsk05>
en.wikipedia.org: m4 (computer language) - Wikipedia
<heat>
one day I'll take whatever the original BSD people took when they were writing code, and I'll try some autotools for my own projects
<sham1>
Don't
<sham1>
Autotools is literal hell
<sham1>
Like literally
<sham1>
It will be fire and brimstone everywhere
<heat>
dont worry I'll be on a mix of crack and LSD, I won't feel anything
<epony>
it's very simple
<immibis_>
autotools is basically macros to write configure scripts, right?
<immibis_>
and configure scripts are to auto-detect which of your 500 supported platforms you are trying to build the software on
<heat>
yeah, i guess
<immibis_>
so if you don't support 500 platforms you don't need it
<epony>
you need a tool like it
<heat>
yes
<epony>
and you will inevitably invent it, with a simple and incoplete design
<heat>
but afaik the 500 platforms part isn't opt-in
<immibis_>
heat: I read that it had to be a macro language because there were too many differences between shells to use features like functions
<heat>
I don't want it as a shell script at all
<epony>
macros come from earlier developments in programming
<heat>
I would like an interpreted language like meson is
<epony>
that's just replacing perl with python
<epony>
nothing more
<immibis_>
then your users have to install meson
<heat>
sure, and That's Fine
<epony>
(and losing some 25-30 years waiting for python and its rewrites)
<heat>
the users also need to install make, make isn't a poorly cobbled together set of macros and shell scripts
<heat>
it could've been, but the old UNIX geezers were better than that
<epony>
back then, there was not even perl
<epony>
https://en.wikipedia.org/wiki/Make_(software)#Origin "It was originally created by Stuart Feldman in April 1976 at Bell Labs. Feldman received the 2003 ACM Software System Award for the authoring of this widespread tool." --30 years to grasp the importance
<bslsk05>
en.wikipedia.org: Make (software) - Wikipedia
<jimbzy>
Make? Never heard of it...
<epony>
makemake laughs at you
<mrvn>
*sing* make, make, make a make, make a make you made....