<heat>
after all these years I still don't understand x86 opcodes
<heat>
don't blame me, they're confusing as hell
<j`ey>
pop sounds like it would crash
<kazinsal>
I can't remember the exact specifics of the way the prefix decodes but one bit in the prefix makes the operand size 64 bits and another makes it the upper 8 register bank so instead of EDX with the prefix it becomes R10
<heat>
pop shouldn't crash
<heat>
hopefully
<heat>
unless you get really unlucky with the stack's positioning
<heat>
in which case, blame UEFI
<heat>
ngl though, arm64/riscv's boot protocols are great
<heat>
linux's x86 boot protocol is a big fucking mess
<bslsk05>
docs.kernel.org: 1. The Linux/x86 Boot Protocol — The Linux Kernel documentation
<heat>
take a shot every time you read something that came straight out of the BIOS. an extra one for "obsolete"
<clever>
hmmm, the 32bit protocol appears to be seperate from the realmode protocol
<heat>
see ya in ER for alcohol poisoning
<clever>
heat: what about deprecated?
<heat>
two for deprecated
<clever>
:D
<heat>
" zImage deprecated but still supported."
<CompanionCube>
finish it for 'removed'
<heat>
compress(1) > any other compression format
<clever>
aarch64 dropped support for zImage, the kernel expects things to already be uncompressed, and that makes the startup code far simpler
<heat>
CompanionCube, there's no removed
<CompanionCube>
aww
<heat>
linux doesn't break ABI baby
<heat>
clever, you mean bzImage
<clever>
and to my surprise, aarch32, simply cant run in a non-compressed manner (except maybe XIP)
<heat>
bzImage = .bz2
<heat>
zImage = .Z
<clever>
heat: the compression form in aarch32 is selectable, so it could be any
<klange>
I use gzipped ramdisks, but uncompressed kernel these days.
<clever>
but in aarch64, there is no compression allowed
<heat>
no compression allowed is weird though
<clever>
if you want a compressed kernel, then the bootloader is responsible for uncompressing it
<gog>
heat: Although the bz prefix may suggest that bzip2 compression is used, this is not the case.[citation needed] (The bzip2 package is often distributed with tools prefixed with bz, such as bzless, bzcat, etc.)
<heat>
i would think you'd save a nice bit of time by compressing
<gog>
:D
<clever>
thats the rule aarch64 set
<heat>
gog, what
<j`ey>
heat: bootloader does it, no need for the kernel to
<heat>
oh ok so it's still supported
<heat>
wtf though
<clever>
with aarch32, the self-decompression is a mess
<heat>
"The bzImage was compressed using gzip until Linux 2.6.30,[3] which introduced more algorithms. "
<heat>
seriously
<heat>
wtf
<clever>
the kernel isnt at the right address, so asm code has to apply relocation patching to c code
<clever>
in order to run the compiled gzip/bzip code
<clever>
and then it drops BACK to asm again, sets up the paging tables, and switches on the mmu
<clever>
and now its virtually at the right addr, so no relocations needed
<gog>
heat: b stands for "big"
<gog>
in this case
<heat>
big zip image
<clever>
with aarch64, it instead just sets up pagint tables, and turns on the mmu
<clever>
simple!
<heat>
thicc zip
<heat>
tzImage
<heat>
a big chonky kernel
<clever>
oh, i just had a thought, on why bootloader decompression is faster
<clever>
it can decompress the file, as its waiting for disk io
<heat>
edk2 can do async IO
<heat>
well, UEFI
<clever>
but with aarch32 self decompression, it can only start to decompress, after it has finished all disk io
<clever>
which slows it down
<gog>
heat: vmchungus
<heat>
aw shit
<heat>
i want that
<mrvn>
If the time to load the kernel is your biggest problem then you have other problems
<heat>
find -type f -exec sed -i 's/onyx/chungus/g' {} \;
<bslsk05>
'BIG CHUNGUS | Official Main Theme | Song by Endigo' by Endigo (00:01:51)
<heat>
𓂸
<heat>
hold this
<clever>
mrvn: i checked my irc logs, and i was getting 400kbyte/sec initially, then i later increased it to 1300, 4800, and there is one weird spike of 6700/sec
<clever>
so thats taking ~1.5 seconds to load the linux kernel from disk
<geist>
HELO PEOPLE
<geist>
i'm back from CANADA
<heat>
HELLO GHOST
<heat>
WHAT IS UP
<klange>
EHLO
<clever>
plus an unmeasured amount of time for linux to decompress itself
<geist>
CANADA WAS NICE EVERYONE WAS NICE
<clever>
geist: and you didnt visit me? lol
<heat>
TYPICAL CANADA
<kazinsal>
geist: you were in canada?
* gog
mews at geist
<geist>
yah did a little weekend drive up across border and over to Kelowna, BC
<clever>
ah, your on the wrong coast for that
<kazinsal>
nice
<clever>
i'm way over in NB
<geist>
nice wine town though a bit fancy
<kazinsal>
Kelowna's one of the nicer towns in the interior
<mrvn>
1.5s is $ calc "1.5/(266*24*60*60)*100" = ~0.00000652673350041771 of my uptime. Do I care?
<heat>
are you a wine person
<heat>
mrvn, if your shit needs to be responsive, yes
<heat>
imagine your car's internal computer taking 3 or 4 seconds to load
<geist>
yah they're really building it up too. lots of really ritzy wineries
<mrvn>
heat: then don't crash it
<heat>
even when starting it up
<heat>
takes long to load = frustrating, cheap
<clever>
that is a common complain i see with the CM4, you dont get any hdmi output for up to 15 seconds, when you turn it on
<mrvn>
heat: why would you cold start the car? You have the kernel running for the theft protection.
<heat>
i unno
<heat>
its just an example
<heat>
you get what I mean
<mrvn>
Problem wiht the RPi is that you can't use sleep mode
<heat>
responsiveness is important in a few situations
<clever>
mrvn: and the reason the cm4 is worse then the cm3, is that the ddr4 training is so slow
<clever>
ive heard that x86 avoids that issue, by caching the training data in the bios config
<clever>
but RPF doesnt care to do it
<mrvn>
heat: like in clervers example the system takes 15 seconds to come up. the 1.5s to load the kernel isn't your main problem.
<bslsk05>
github.com: lk/arch.c at arm64_shutdown · littlekernel/lk · GitHub
<mrvn>
heat: that's all messages. the shell doesn't mess with hardware
<clever>
and i always have 2 other options, uboot and uefi
<heat>
ok, not saying it does
<heat>
but it makes sense to make things wait for other things
<j`ey>
what happens if the interript driver never loads?
<heat>
clever, lk can kexec? that's pretty cool
srjek|home has joined #osdev
<mrvn>
heat: totally. You probably want the shell on the UART and that needs the interrupt processor
<clever>
heat: yeah, i'm using it in 2 places, on the VPU side so an lk.bin can execute an lk.elf, and then again on the arm32 side, to execute a zImage
<mrvn>
heat: so at least RPi interrupts need to be up
<heat>
clever, huh? so what exactly can it kexec?
<heat>
can it kexec lk only? can it kexec anything? any elf?
<bslsk05>
github.com: lk-overlay/loader.c at master · librerpi/lk-overlay · GitHub
<clever>
heat: LK just disables the mmu, and runs the specified entrypoint, with 4 args, in r0/r1/r2/r3
<clever>
anything that fits that api can be ran
<heat>
ah ok
<j`ey>
mrvn: which it could, and then replace it self later on maybe
<clever>
heat: the code i just linked, involves loading and patching a dtb, to make linux happy
<mrvn>
heat: I'm actually thinking of having the UART start in polling mode and then switch over to IRQ driven mode at runtime.
<heat>
what's so special about that logic though?
<clever>
heat: you have to flush the caches as you turn off the mmu, and you cant touch any ram during that process
<mrvn>
heat: just to have an early_printk
<clever>
heat: if you get a cache hit while the cache is "off", that is a fatal exception, because the cache is technically never off
<heat>
clear the cache?
<mrvn>
clever: won't at least the cache line with the opcode to switch cache off be in cache?
<clever>
heat: the arm32 chainload code, also had issues, because the identity map for turning the mmu back off, was in the userland half of the split, and didnt even get mapped
<heat>
cant wait for you to send me to 200 pages of cache behavior in the arm arm
<clever>
mrvn: i-cache doesnt count, only d-cache
<j`ey>
only 200?
<heat>
oh yeah
<heat>
400
<heat>
at least
<heat>
the first page sends me straight to another chapter
<bslsk05>
github.com: lk/arch.c at master · littlekernel/lk · GitHub
<j`ey>
do not pass go, do not collect $200
<clever>
reviewing this code to explain the basics
<clever>
310-316 turns irq's off, and tells the drivers to de-init most hw, so things wont be running around and stepping on the new kernel
<heat>
CC420_EL1 controls ARM's cache behavior when spongebob squarepants shows up in the secure world
<j`ey>
lol
<j`ey>
spongebob securepants
<clever>
323 converts the virtual address of the new kernel into a physical address
<heat>
aw fuck that was a great pun
<clever>
333 then does the same for the asm helper routine
<clever>
340-356 identity maps the asm helper, so you can jump to it in virtual mode, and when it turns the mmu off, the addr is also valid in phys mode
<clever>
and deals with creating a userland paging table set if needed
<clever>
368 flushes the cache and disables it
<clever>
374 turns some more stuff off, and then 383 runs the asm helper
<bslsk05>
github.com: lk/asm.S at master · littlekernel/lk · GitHub
<clever>
and the helper just shuffles args around, because C gave it the args in the wrong order
<clever>
then turns the mmu off, and jumps to the entry point
<heat>
arm is for weirdos
<heat>
the only valid architectures are itanium and ia32 under itanium
<clever>
i think the biggest problem i ran into, was a lack of aarch64 arch_disable_cache
<heat>
this is why intel doesn't offer me a job
<heat>
i should pretend itanium didn't exist
<heat>
amd64? what's that? i'm only familiar with intel 64
<CompanionCube>
itanium has Integrity after all
<gog>
itanium is love itanium is life
<heat>
yeah there was a weird gap between the pentium and intel 64, intel just kinda stopped innovating I guess
<heat>
nothing notable happened
<heat>
amd did invent titanium, which flopped
<heat>
intel would never
foudfou_ has joined #osdev
gxt__ has quit [Remote host closed the connection]
<geist>
well, i think there *was* a huge brain sink there where intel was pretty much doing that: they dumped all their design energy into itanium in the late 90s or so
<geist>
since it came out in 2001. they had been working on it for a long time prior to that
gxt__ has joined #osdev
gog has quit [Ping timeout: 240 seconds]
foudfou has quit [Remote host closed the connection]
<heat>
are there good docs on the process of making a new CPU arch/micro-architecture?
<heat>
that whole process is a blackbox to me
<heat>
specifically iteration, testing, verification, other constraints you need to take care of
<heat>
I suppose you don't spin up vscode and your favorite systemverilog plugin and get at it
<CompanionCube>
itanium also killed off alpha and pa-risc to add on the sinkiness
<heat>
i know they extensively use simics when doing fw platform validation
<heat>
alpha was alpha but itanium was sigma
srjek|home has quit [Ping timeout: 244 seconds]
gxt__ has quit [Ping timeout: 268 seconds]
srjek|home has joined #osdev
gildasio has quit [Quit: WeeChat 3.5]
gxt__ has joined #osdev
srjek|home has quit [Read error: Connection reset by peer]
particleflux has quit [Quit: 418 I'm a teapot]
ozarker has quit [Remote host closed the connection]
<bslsk05>
ringzeroandlower.com: Booting from Grub2 to x86 long mode (64-bit mode)
<klange>
shoot
k8yun has joined #osdev
<coso>
linker script provided seems to have grub make the kernel iamge at 4m in physical memory
<coso>
and then for the 64bit code it uses some negative half virtual memory
<coso>
I want to define a common symbol in bss, modify that piece of memory in 32bits code, and then access it from virtual memory from C as an 'extern int foo;'
<coso>
how do i get around doing that? doing it in the most naive way i get the symbol foo defined, but its the physical address, not the virtual 64 bit one
<klange>
&_kernel_virtual_start - &_boot_end should give you the difference between those virtual addresses and physical addresses.
doug16k has joined #osdev
<coso>
can i just drop &_kernel_virtual_start in C code?
<coso>
should i have to declare that with extern as a pointer?
<doug16k>
make it char _kernel_virtual_start[]; and it is more true to reality
<doug16k>
don't even need & then
<klange>
Generall you declare it as a char[]
<coso>
makes sense
<klange>
Yeah yeah, I was speaking pseudocodily - you want the address specified by the symbol, rather than, like, the content of it.
<heat>
I usually declare them as extern char _sectionX_start;
<heat>
because i'm a psycho
<doug16k>
heat, it's not true right?
<heat>
it is
<doug16k>
there's no char there
<heat>
idc
<heat>
arrest me
<klange>
I'm sure there's probably something there for the ones you put at the start of a section... just, not one you care about...
<doug16k>
different ways work, whatever coerces it to get the address of a symbol. I like the char array thing because it is closest to the truth
<doug16k>
if you really made a global array, it would be the same as that _kernel_virtual_start
<doug16k>
...that came from the linker script
<doug16k>
where just saying that name means that address
<klange>
♫ say my name say my name ♫
<doug16k>
oops, I meant extern char _kernel_virtual_start[];
<Mutabah>
^ that's much better
<klange>
yes, the extern is important
<doug16k>
if you want to be even more careful, add const. If you use any variables to point to there, make them pointer to const
<doug16k>
then do your arithmetic or whatever on those
gxt__ has quit [Remote host closed the connection]
gxt__ has joined #osdev
k8yun has quit [Quit: Leaving]
heat has quit [Ping timeout: 240 seconds]
SpikeHeron has quit [Ping timeout: 240 seconds]
air has quit [Ping timeout: 246 seconds]
air has joined #osdev
SpikeHeron has joined #osdev
air has quit [Ping timeout: 244 seconds]
air has joined #osdev
[itchyjunk] has quit [Read error: Connection reset by peer]
Vercas has quit [Quit: buh bye]
Vercas has joined #osdev
<coso>
hey thanks guys it worked
<coso>
i managed to screw it up at first lol because i got bamboozled by the linker script
<coso>
specifically why .text gets that AT(_boot_end) thing
<doug16k>
that is the address it got loaded, but the code there thinks it is at the vaddr
<coso>
i understand that we want to do that . += 0xFFFFFF..... thing to map the kernel to the top half of memory
<coso>
so the "." thing is always the vaddr?
<coso>
and AT is phyisical?
<doug16k>
think where it was loaded AT
<doug16k>
not physical
<doug16k>
sort of physical yeah
<doug16k>
it could be a ROM, at some weird address, and you copy it, and there is no virtual memory
<doug16k>
it would be AT the rom, vaddr where you copy it
<doug16k>
usually you just copy a whole ROM to RAM at the beginning and forget the ROM
<doug16k>
ROM isn't pipelined, performace sucks
<doug16k>
that is the "real" purpose of AT, but we reuse it for handling how the bootloader put it at some low address but we make it be at a high address
<coso>
I see
<coso>
I need to understand ELF better
<coso>
i still dont get clearly whats what in the file vs runtime
<coso>
if you just dont provide an AT command
<coso>
what does the linker do about that?
<Mutabah>
It defaults to the load address being the current/linked address
<Mutabah>
I.e. as if it had `AT(.)`
<doug16k>
yeah, once you create a difference between them, they both advance together
<doug16k>
before and after they advance together. you can make a difference between them
<Mutabah>
^
<doug16k>
my bootloader doesn't even do any AT games because my bootloader enters the kernel with it already high
<doug16k>
the bootloader puts it in whatever pages
<coso>
im aiming for grub because thats what i already have anyway
<doug16k>
grub will put it where you say to put it with AT
<coso>
hmm
<doug16k>
you could probably put a silly address and cause grub to fail or overwrite itself
<doug16k>
you could put it outside ram and overwrite some alias
<coso>
my brain istn working at 100% rn
<coso>
lol
<doug16k>
most likely 0x100000 works
<coso>
would grub mess up and write over memory mapped stuff?
<doug16k>
maybe. I wouldn't be shocked if it just did what you said naively
<coso>
grub provides a pointer to some memory data structs (thats what i wanted to access anyway)
<coso>
anyway thanks a lot!
<coso>
imm off to bed
coso has quit [Quit: Leaving]
toluene has quit [Ping timeout: 244 seconds]
toluene has joined #osdev
SGautam has joined #osdev
DonRichie has quit [Quit: bye]
toluene has quit [Quit: Ping timeout (120 seconds)]
<mrvn>
grub can also ignore the ELF header and load the kernel as raw image and then you have to relocate yourself.
eroux has quit [Ping timeout: 264 seconds]
eroux has joined #osdev
GeDaMo has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
bauen1 has quit [Ping timeout: 276 seconds]
<kazinsal>
geist: whenever you see this, I'm thinking of doing a road trip down to seattle the week of the first. any recommendations for stuff to see? I'm hoping to hit up the connections museum and the living computer museum if it's open
<kazinsal>
it's been almost a decade since I've been down that way
bauen1 has joined #osdev
gog has joined #osdev
gorgonical has quit [Ping timeout: 252 seconds]
bradd has quit [Ping timeout: 268 seconds]
bradd has joined #osdev
pretty_dumm_guy has joined #osdev
witcher has left #osdev [#osdev]
heat has joined #osdev
the_lanetly_052 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 244 seconds]
SGautam has quit [Quit: Connection closed for inactivity]
SGautam has joined #osdev
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 276 seconds]
X-Scale` is now known as X-Scale
wgrant has quit [Ping timeout: 246 seconds]
mats1 has quit [Quit: Connection closed for inactivity]
wgrant has joined #osdev
gildasio has joined #osdev
foudfou has joined #osdev
foudfou_ has quit [Ping timeout: 268 seconds]
bliminse has joined #osdev
SGautam has quit [Quit: Connection closed for inactivity]
vdamewood has joined #osdev
vinleod has joined #osdev
vdamewood has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
gildasio has quit [Write error: Connection reset by peer]
gxt__ has quit [Write error: Connection reset by peer]
foudfou has quit [Remote host closed the connection]
wand has quit [Read error: Connection reset by peer]
Vercas has quit [Read error: Connection reset by peer]
Test_User has joined #osdev
wand has joined #osdev
foudfou has joined #osdev
Vercas has joined #osdev
opal has joined #osdev
gxt__ has joined #osdev
gildasio has joined #osdev
\Test_User has quit [Ping timeout: 240 seconds]
Test_User is now known as \Test_User
dennis95 has joined #osdev
[itchyjunk] has joined #osdev
<zid>
Made in abyss s2 in 20 mins *waits impatiently*
<clever>
lets go!
gog has quit [Ping timeout: 240 seconds]
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
<zid>
welp, see you next week, riko
the_lanetly_052 has quit [Ping timeout: 256 seconds]
tsraoien has joined #osdev
tsraoien has quit [Ping timeout: 276 seconds]
zaquest has quit [Remote host closed the connection]
liz has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
bauen1 has quit [Ping timeout: 255 seconds]
gog has joined #osdev
gorgonical has joined #osdev
vdamewood has joined #osdev
jafarlihi has joined #osdev
vinleod has joined #osdev
gorgonical has quit [Quit: Client closed]
zaquest has joined #osdev
vdamewood is now known as Guest4547
Guest4547 has quit [Killed (lithium.libera.chat (Nickname regained by services))]
vinleod is now known as vdamewood
gorgonical has joined #osdev
gorgonical has quit [Client Quit]
gorgonical has joined #osdev
jafarlihi has quit [Quit: WeeChat 3.5]
gorgonical has quit [Quit: Leaving.]
friedy has left #osdev [#osdev]
friedy has joined #osdev
friedy has left #osdev [#osdev]
gorgonical has joined #osdev
mats1 has joined #osdev
friedy has joined #osdev
<heat>
𓂸 good afternoon friends 𓂸
<heat>
what is up
<zid>
made in abyss s2 and last call bbs
jafarlihi has joined #osdev
<zid>
I'm trying to stop my flesh turning into bone, because the OR gates were feedbacking into their inputs
<zid>
because I couldn't get the nacho cheese to work
<jafarlihi>
Is there like a mailing list or something where you can report bugs or ask questions for AOSP?
<heat>
electrical engineer moment
<heat>
also, new sentence
<zid>
I was thinking precisely that
<zid>
last call bbs is a great game for making you say things that have never been said
<gorgonical>
I'm rebuilding my entire buildroot toolchain because something something uclibc and c++11
bauen1 has joined #osdev
<jafarlihi>
The AOSP Bluetooth stack does not build following the instructions, what should I do?
kuzuy has joined #osdev
nyah has joined #osdev
<jafarlihi>
It is funny how outdated the instructions are, it is as if they don't want people to build it
dennis95 has quit [Quit: Leaving]
<PapaFrog>
TIL we are a support site for AOSP.
<heat>
back in my day this was a support channel for the linux kernel
kuzuy has quit [Quit: ZZZzzz…]
kuzuy has joined #osdev
<mrvn>
must be two decades ago
<jafarlihi>
They just have a box in Google that builds this shit so no one ever tried to follow the instruction in a decade
kuzuy has quit [Quit: Bye!]
kuzuy has joined #osdev
<geist>
zid: oooooh last call bbs, need to order that. Some folks i know ordered the physical kit which i guess isn’t avail anymore. Looked great
<geist>
Had a whole model of the computer and everything
<zid>
nice
<geist>
I have the physical kit for TIS-100 which is pretty nice. It’s a 80s looking binder with a bunch of printed out chip manuals and whatnot
<zid>
yea I did see some of the simpler ones
<geist>
Also need to start S2 of MiA, but i haven’t had a chance to find a stream of the movie yet, which I should watch first
<geist>
Also need to make sure I’m emotionally stable before starting such a show as that
<zid>
yes you should absolutely watch it first
<zid>
It was streamed on 'hidive' or something for $18 when it released
<zid>
and beyond that it's BD only I think
<geist>
It’s annoyingly hard to find in the states. I looked up the reasoning, apparently some company got some sort of exclusive rights to it before they launched their new streaming service, and then didn’t launch
<geist>
Was fairly unplugged the last weekend. Pretty nice to do that sometimes
<geist>
Yah, though really lets not paste stuff like this in this channel
<geist>
Privmsg please
dude12312414 has joined #osdev
<clever>
geist: and yeah, you need to see the 3rd movie before S2
heat has quit [Ping timeout: 264 seconds]
<geist>
Yah or the 1st movie that’s not just the retelling of S1 i think
<clever>
yeah, movie1/movie2 are a recap of s1
<jafarlihi>
Why do you bitch when I talk about Linux and AOSP yet you talk about fucking movies of all things
<mrvn>
MiA?
<zid>
because we're having a chat between friends about common interests while the channel is quiet, and you're asing us off-topic questions nobody cares about
<zid>
I'd be surprised if anybody had heard of aosp, so you'll have to do your own research, the alternative is that we just do it for you
<zid>
either way someone needs to do it
<jafarlihi>
It doesn't work bro, shit broke
<jafarlihi>
It's easier to dump it from my phone than build it
<zid>
'shit broke' 'doesn't build' etc aren't either conversation starters, or enough info to let someone help you if they wished to
xenos1984 has quit [Read error: Connection reset by peer]
<zid>
so you're basically just talking *at* the channel, that's why nobody is interacting
<sbalmos>
I wrote a lot of code in my head. it didn't compile. I don't know why not, it ran fine in my head.
<moon-child>
I just do dd if=/dev/urandom count=200 of=x.c; cc x.c
<moon-child>
and if it doesn't work I try again
kuzuy has quit [Remote host closed the connection]
jafarlihi has quit [Quit: WeeChat 3.5]
<PapaFrog>
moon-child: I devised a sorting algorithm like that.
<PapaFrog>
I kid.. I'm not that creative.
<moon-child>
bogosort?
<moon-child>
or stacksort?
xenos1984 has joined #osdev
<doug16k>
moon-child, if only people fuzzed stuff like that more often
<gorgonical>
moon-child: I have nothing better to do and so I'm running this
<gorgonical>
In a loop until it compiles
<PapaFrog>
How long until the heat death of the universe?
<PapaFrog>
And what is the period of urandom?
Piraty has quit [Quit: -]
Piraty has joined #osdev
<gorgonical>
I have restrained it to the smallest 12-byte legal c program
<gorgonical>
I only need like a supercomputer to actually churn through these
<\Test_User>
mrvn: can probably do that with some compressed data put into the source that when decompressed includes itself
<mrvn>
\Test_User: that is rather complex to do
<\Test_User>
never said it was easy, just said it can be done
<mrvn>
Usualy you define some strings for the stuff before the print and after the print and then print the suff before twice and the stuff after twice kind of.
<mrvn>
It's sad that my soltion doesn't work with GCC anymore.
<\Test_User>
makes sense
<mrvn>
Well, not really my solution. That was an entry to the obfuscated-c-contents and won the price for biggest missuse of the rules.
Celelibi has quit [Ping timeout: 244 seconds]
<gorgonical>
So the files that get turned into object files is actually pretty large
<gorgonical>
But it generates empty stubs in the case of e.g. 5 spaces
<gorgonical>
So I need some way to determine if the generated elf stub actually contains anything
<mrvn>
do they differ?
rorx has quit [Ping timeout: 244 seconds]
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
<gorgonical>
yeah, it seems I could diff them
<gorgonical>
in the case of 'f;' nm will show a symbol. So maybe nm output can be used to reject empty stub programs
<gorgonical>
empty stub object files*
<mrvn>
shasum them
<gorgonical>
even easier
<mrvn>
only keep a source if it's unique or shorter
<clever>
mrvn: that sounds like git
<gorgonical>
with shasum support it now rejects stub object files
<gorgonical>
the first C file I got was '_z;'
<mrvn>
I would exclude everything with warnings
<mrvn>
are you counting how many random files compiler and not compile?
<gorgonical>
At this point I'm only county empty stub rejects
<gorgonical>
The number of bytes to generate is also randomly picked
<gorgonical>
Seems like almost all contenders end up being labels ending with semicolons
<mrvn>
labels end in :, those are identifiers
<gorgonical>
oh right
<gorgonical>
of course
<mrvn>
And a lable must be followed by a statement
<gorgonical>
so then probably all valid files will be identifiers
<gorgonical>
Because given the 8-byte sequence there's exactly one way to generate the main stub
<mrvn>
not much you can do with the remaining 4 bytes
Vercas has quit [Remote host closed the connection]
<mrvn>
just enough to "a=1;"
Vercas has joined #osdev
<mrvn>
gorgonical: here is another stub for you: main=0xc3;
<mrvn>
makes me wonder what the probability is that /dev/random outputs hello-world
<kingoffrance>
consider charset is (or was) not mandated. good odds :D
<kingoffrance>
he who controls the spice....controls the universe!
<mrvn>
fear is the mind killer
<gorgonical>
mrvn: i get segfault when I run that
<gorgonical>
But it does link
<gorgonical>
very important
<mrvn>
gorgonical: Does it put "main" in .data?
<mrvn>
0xc3 should be "ret" on x86
<gorgonical>
yes I have a main section with retq
gildasio has quit [Quit: WeeChat 3.5]
<gorgonical>
It would take an exascale computer approximately an hour to generate that from bytes
<mrvn>
35: 0000000000004028 4 OBJECT GLOBAL DEFAULT 24 main
<mrvn>
main __attribute__((section(".text"))) = 0xc3;
<mrvn>
can't make that fit in 12 chars :(
<mrvn>
but isn't that a nice hacky way to include inline asm?
<gorgonical>
I wonder if there's a compiler directive you can pass on command line
<gorgonical>
like -Qn to cut the .comment section
<mrvn>
you can supply a linker script
<gorgonical>
that would definitely be the best you could do then
opal has quit [Remote host closed the connection]
opal has joined #osdev
heat has joined #osdev
<heat>
re: aosp tbf I know what aosp is
<heat>
and it does need to build since its, you know, built thousands of times each day by google and 300 other vendors or whatever
<heat>
very likely this is a PEBKAC situation
<gorgonical>
Adding -z execstack marks the .data section exec and so we can actually run main=0xc3;
<gorgonical>
Probably the minimal program a c compiler will accept
<heat>
-z execstack marks .data exec?
<gorgonical>
At least in the case of that above 9-byte program
<gorgonical>
It puts the main symbol into the data section
<heat>
doesn't -z execstack just mark the stack as executable?
<heat>
that was my understanding of it
<heat>
hence -z noexecstack
<gorgonical>
Yes it would seem that's the case
<gorgonical>
I'm trying to examine the object file differences and can't really find out what's different
<gorgonical>
but clearly removing -z execstack causes the program to segfault
nyah has quit [Ping timeout: 244 seconds]
<gorgonical>
xxd shows a difference but objdump only shows a very small difference in the .note.gnu.build-id section, which I don't think is responsible
<gorgonical>
Suppressing that section means there's only a single bit different between the files, so that must be responsible for it
<heat>
.note.gnu.build-id is just a hash
rorx has joined #osdev
<gorgonical>
Yeah I'm trying to figure out how to make objdump show me that bit difference. I see the bit in xxd
<mrvn>
use readelf
<gorgonical>
thank you
<gorgonical>
I don't use readelf often so it didn't come to mind
<heat>
bruh
<heat>
I only use readelf
<heat>
objdump is beta GNU BFD crap
<heat>
readelf is top tier ELF utility
<gorgonical>
I will keep that in mind
<gorgonical>
readelf certainly produces much much more information
<zid>
(readelf is also part of binutils :P)
<zid>
I don't actually know how zexecstack manifests but I am too lazy to google, I would assume a flag in a .gnu section flips a bit and then ld.so does a different mmap?
<mrvn>
obviously. it sets the execute bit
<heat>
not ld.so, the kernel
<heat>
execstack adds a GNU_STACK header with the X bit set
<heat>
the kernel reads that and makes your stack executable
<heat>
s/header/program header/g
<zid>
the kernel itself does? I'm just used ld.so doing everything not nailed down
<heat>
also, funnily enough I've seen readelf as part of coreutils implementations
<zid>
why else would there be an interpreter field!
<heat>
nah, ldso doesn't allocate the stack or anything
<mrvn>
zid: the kernel has to do it for when there isn't one
<heat>
ldso relocates itself, loads your program's dependencies, relocates the program, and jumps to it
<zid>
It could if it tried hard enough
<heat>
the kernel is still responsible for the auxv + stack + loading the program and the interpreter into memory