<heat_>
zid, problem is that given a valid ELF that has "PHDR 0 vaddr 0 size N, PHDR 1 vaddr N size Y" mmap(vaddr) won't work
<heat_>
neither will mmap(NULL), FWIW
<heat_>
you need to find the .so's loaded size, mmap(NULL) that (so you know you have $SIZE contiguous bytes), and then if needed mmap MAP_FIXED over that
<heat_>
Ermine, cuz it asked for gcc and that crap software might not even support clang
<Ermine>
Ah, crappy situation
<Ermine>
Actually, what is meant by supporting clang? Iirc clang has gcc-compatible cli
<heat_>
gcc and clang aren't completely compatible
<heat_>
particularly when it comes to warnings
<heat_>
though i guess they probably don't turn on warnings either lol
<heat_>
also, consider that you have no way to inject command line args without a wrapper
<heat_>
(for that cursed program)
<heat_>
anyway point is that installing software on windows is fucking cursed
<Ermine>
Agreed
<heat_>
cuz i went to a lot of trouble to get a working setup there
<heat_>
when in my case I could've done "sudo pacman -S spin gcc" and it literally works
<Ermine>
Though I made msvc, cmake and qt to work together today
<heat_>
msvc ain't too bad
<Ermine>
Under linuks you don't need a special developer command prompt
<Ermine>
You just open terminal and use your tools
<Ermine>
Would be nice to have clang to do the job, but qt doesn't provide binaries built for clang
<heat_>
sure, but opening a supar special terminel is like, the only worry there
<heat_>
versus figuring out which one out of "mingw, mingw64, cygwin, msys2, wsl1, wsl2, clang for windows" you want to install
<Ermine>
Well, you have to choose between gcc and clang on linux as well
<Ermine>
Imo the worst part is to make all that stuff to work together
<Ermine>
Desirably, without installing visual studio
<gorgonical>
Okay so as much as I can tell Linux and netbsd both basically just put the first interpreter segment where it says to go in the elf
<gorgonical>
which is probably gonna be like 0x40 or 0x0 in many cases
<gorgonical>
at least that's how I'm reading this code
<bslsk05>
github.com: src/sys/kern/exec_elf.c at 832b64785c4343d5e885eac92e0f848ab1f4120c · NetBSD/src · GitHub
<heat_>
gorgonical, what
<gorgonical>
I'm just trying to wrap my head around how other kernels choose where to put the interpreter
<heat_>
they put the interpreter wherever mmap wants to
<heat_>
ET_DYN gets relocated, it doesn't get placed in a fixed location
<zid>
gorgonical: are you envisioning some 'bad' location it could end up?
<zid>
You know it's getting freed after, right?
<heat_>
huh?
<gorgonical>
heat_: okay so mmap just finds some hole in the process vaddr to stick the section, hinted by whatever address gets picked here. but that hint will be probably 0x0 is my point
<zid>
0 is not a hint, it's a direct value that means "Pick for me"
<heat_>
not sure if it gets hinted at all
<gorgonical>
Oh yes
<gorgonical>
I suppose that's true
<heat_>
it is
<zid>
If addr is NULL, then the kernel chooses the (page-aligned)
<zid>
address at which to create the mapping; t..
<gorgonical>
Of course it is
<gorgonical>
I'm just saying it *is* providing a hinting address as stated by the elf, but that it is 0x0 so mmap should just pick
<Ermine>
FWIW clang on windows needs windows sdk, which includes c std stuff
<zid>
it isn't a hint, it's a direct order
<zid>
The only thing it's "hinting" is.. "not 0", ironically
<gorgonical>
I'm noticing a humorous pattern that a lot of loader code has angrily worded comments referring to how MIPS has a weird design that requires "evil hacks" to accommodate
<heat_>
i think we should map more things at 0
<heat_>
0 is a perfectly good address
<zid>
can I move the null pointer bitrep
<gorgonical>
it's only because we use a language that allows numerical manipulation of addresses that 0x0 is considered a bad address at all
<zid>
I've always wanted a compiler with a non-zeros bitrep
<Ermine>
First 1Mb is considered bad, isn't it?
<zid>
First 2MB I hope
<gorgonical>
zid: cause x86 I/O addresses and such?
<zid>
padun?
<heat_>
no
<zid>
because pages are 2MB, gorg
<heat_>
linux x86 default is 64KiB
<heat_>
IIRC
<zid>
64k is at least 4k page aligned
<gorgonical>
why would addresses within the first 2mb be bad?
<gorgonical>
within the first page*
<zid>
cus it means your address space starts unaligned
<Ermine>
also there's a knob in kernel config on this topic
<zid>
might as well round it to 2, or use something in the 4k range
<zid>
1M is a weird midpoint of blah
<heat_>
i think i use 4MiB on x86 onyx
<heat_>
then 64KiB on riscv cuz the linker actually uses that as the base address by default
<heat_>
and i can't remember what i do for arm
<zid>
Can we just round it up to 1G
<heat_>
no
<zid>
how sure are you
goren has joined #osdev
<heat_>
because then 32-bit compat gets sad
<zid>
what's that
<heat_>
and the default base address for x86_64 ELF is 4MiB
<heat_>
for most linkers
<goren>
ableos is amazainag
<goren>
and good
<heat_>
sounds ableist
<gorgonical>
heat_: you said earlier that things get relocated. I know that the loader has to do relocations for the actual payload program, but does it relocate itself?
<goren>
heat_, ableos is not ableist :3
<heat_>
gorgonical, yes
<zid>
boo
<zid>
I am ableist
<goren>
also why is discrimination against neurodivvergent people considered ableism?
<goren>
as a neurodivergent person i think it's a completely different thin
<zid>
overreach
<goren>
*thing
<goren>
(sorry for being offtopic)
<gorgonical>
I guess it makes everything easier when the loader puts itself at some internally-known address before you go loading new segments
<gorgonical>
well I guess the question is when does the loader relocate itself?
<heat_>
at startup
<heat_>
its first few instructions will be position independent code that grabs its base address and relocates itself
<heat_>
note that static PIE executables also need to do it themselves
heat_ has quit [Remote host closed the connection]
<gorgonical>
so very similar to the jump from physical memory to virtual memory addresses in a kernel's head.S
heat has joined #osdev
<heat>
gorgonical, kinda
<heat>
the constraints are similar
<heat>
you're running at the "wrong address"
<gorgonical>
just in the sense that it's done as soon as practical and there's some internal calculation and relocation to a known address
<bslsk05>
github.com: musl/ldso/dlstart.c at master · heatd/musl · GitHub
<heat>
excuse the musl
<Ermine>
Wow, it has comments!!!!!!!!!!!11!1!
<gorgonical>
it gets its base and then calls dls2 which I think is in dynlink.c right? Trying to find where it actually does the reloc
<heat>
it does the reloc right there
<heat>
the immediately needed ones that is
<heat>
(RELATIVE)
<gorgonical>
so it doesn't do any remapping to a known address. I had assumed that. It just computes the relative offset of some symbols based on its load address
<heat>
why would it?
<gorgonical>
not sure. There's a lot of gaps in my understanding of exactly how libc and the whole program toolchain works
<gorgonical>
It would be repeated work but maybe I hadn't considered all the reasons why you might want to do that
<heat>
you don't want known addresses because you don't know if that address is available for you
<heat>
it's also a good ASLR bypass
<gorgonical>
Yes so that's a good point. You want mmap to just select for you to bypass this. mmap of course being capable of respecting aslr too
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
[_] has quit [Ping timeout: 256 seconds]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
pebble has quit []
JTL is now known as JLT
JLT is now known as JTL
m3a has joined #osdev
gabi-250_ has quit [Remote host closed the connection]
foudfou has quit [Remote host closed the connection]
gabi-250_ has joined #osdev
foudfou has joined #osdev
zetef has joined #osdev
zetef has quit [Remote host closed the connection]
zetef has joined #osdev
[itchyjunk] has quit [Read error: Connection reset by peer]
netbsduser has joined #osdev
SANiK has quit []
bitoff has joined #osdev
netbsduser has quit [Ping timeout: 256 seconds]
gbowne1 has quit [Quit: Leaving]
bliminse has quit [Quit: leaving]
xenos1984 has quit [Read error: Connection reset by peer]
bitoff_ has joined #osdev
bitoff has quit [Ping timeout: 246 seconds]
bitoff_ has quit [Remote host closed the connection]
bliminse has joined #osdev
xenos1984 has joined #osdev
zetef has quit [Ping timeout: 264 seconds]
goliath has joined #osdev
muffin has joined #osdev
Yoofie7 has joined #osdev
muffin has quit [Ping timeout: 245 seconds]
Yoofie has quit [Ping timeout: 252 seconds]
Yoofie7 is now known as Yoofie
zetef has joined #osdev
GeDaMo has joined #osdev
zetef_ has joined #osdev
zetef has quit [Ping timeout: 256 seconds]
danilogondolfo has joined #osdev
Left_Turn has joined #osdev
eddof13 has joined #osdev
bauen1 has quit [Ping timeout: 245 seconds]
eddof13 has quit [Ping timeout: 246 seconds]
heat has joined #osdev
gildasio has quit [Quit: WeeChat 4.0.4]
zetef_ has quit [Ping timeout: 260 seconds]
Yoofie3 has joined #osdev
Yoofie has quit [Ping timeout: 252 seconds]
Yoofie3 is now known as Yoofie
pretty_dumm_guy has joined #osdev
pretty_dumm_guy has quit [Client Quit]
zetef has joined #osdev
Left_Turn has quit [Ping timeout: 256 seconds]
zetef has quit [Ping timeout: 252 seconds]
pretty_dumm_guy has joined #osdev
Left_Turn has joined #osdev
muffin has joined #osdev
muffin has quit [Ping timeout: 268 seconds]
stolen has quit [Quit: Connection closed for inactivity]
zxrom has joined #osdev
srjek|home has joined #osdev
muffin has joined #osdev
bauen1 has joined #osdev
srjek|home has quit [Ping timeout: 276 seconds]
bauen1 has quit [Ping timeout: 264 seconds]
bauen1 has joined #osdev
<[Kalisto]>
hi! noob question! I am writing a paging mapper in x86 and I get to page the virtual address to an specific frame (to the vga buffer, just to test the mapper). The translator gives me the correct mapping virtual 0x0 -> phys 0xb000, but when I try to write it i get a double fault. Do i need to write some flags in the intermediate tables?
<zid>
qemu will tell you precisely what happened if you run with -d int
<[Kalisto]>
awesome, thanks! gonna look for that
<zid>
(0 is a very weird place to map things to btw)
XgF has quit [Ping timeout: 268 seconds]
<zid>
also you want 0xb8000
<zid>
or 0xA0000
<zid>
16bit segmented b800:0000 -> 0xb80000 linear, if it wasn't just a typo
<zid>
0xb8000*
XgF has joined #osdev
<[Kalisto]>
i am following phillip op rust tutorial (coding x86 myself), the page 0 has already all the intermediate tables created that's why
<[Kalisto]>
just for testing
<[Kalisto]>
still have to code the allocator
<zid>
no idea what any of that means
<zid>
0 is just a very odd address to map something to, almost nody wants 0 to be a valid address
<[Kalisto]>
oh is just for testing, the tutorial i am following garantees that virtual adress 0 has all the page tables allocated, so i only have to modify the last one
<Mutabah>
link?
<Mutabah>
also, it seems very strange for virtual `0` to map to anything other than physical 0
<Mutabah>
(or be unmapped, which is a much better idea after really early boot)
<zid>
why would you *ever* map it, you messing with the real mode IVT from a paged environment?
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
<Mutabah>
identity mapping before jumping to high memory