<zid>
well that hardly seemed worth it, isp updated their packages and I had to reboot for new config file, 110Mbps -> 140Mbps
wand has joined #osdev
wand has quit [Remote host closed the connection]
nur has quit [Read error: Connection reset by peer]
wand has joined #osdev
zhiayang has quit [Quit: oof.]
zhiayang has joined #osdev
zhiayang has quit [Client Quit]
zhiayang has joined #osdev
sebonirc has quit [Read error: Connection reset by peer]
sebonirc has joined #osdev
Mondenkind has quit [Quit: !]
moon-child has joined #osdev
elastic_dog has quit [Quit: elastic_dog]
elastic_dog has joined #osdev
Gooberpatrol66 has joined #osdev
smach has joined #osdev
smach has quit []
nyah has quit [Ping timeout: 246 seconds]
srjek|home has joined #osdev
wand has quit [Ping timeout: 255 seconds]
Vercas6 has joined #osdev
wootehfoot has joined #osdev
poyking16 has joined #osdev
poyking16 has quit [Client Quit]
Vercas6 has quit [Quit: Ping timeout (120 seconds)]
weinholt has joined #osdev
vdamewood has joined #osdev
poyking16 has joined #osdev
poyking16 has quit [Client Quit]
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
elastic_dog has quit [Ping timeout: 246 seconds]
elastic_dog has joined #osdev
nur has joined #osdev
ptrc has quit [Remote host closed the connection]
ptrc has joined #osdev
heat has joined #osdev
<heat>
zid, +30mbps? that sounds very worth it
Dyskos has quit [Quit: Leaving]
<zid>
It's basically identical
<zid>
I'm more used to it doubling, but speeds have basically plateau'd now
<zid>
nobody's going to over above 1gbps as their top package for a long long time
<zid>
same with ram around 32GB, drives in the low tens of terabytes, etc
<zid>
cpus around 4-5GHz
<zid>
the only thing that's had any kind of explosion is L3 cache on certain $8000 server amd cpus
<heat>
you have way more than 32GB of ram
<heat>
even desktop mobos support more than that I think
sympt has joined #osdev
<heat>
the 12900k supports 128 GB
Bonstra has quit [Quit: Pouf c'est tout !]
<zid>
support more yes
<zid>
and my mobo from 2011 supports PBs of storage
<zid>
but that isn't what people *have*
<zid>
I could also get an OC-384 wired into my room
<heat>
yeah but you were talking about the top package
<heat>
the top package is way more than 32GB on desktop
<GeDaMo>
More cores?
<zid>
I wasn't talking about our top package as though it were a fundamental limit
<zid>
they won't offer more until more is needed
<zid>
and that that has basically stalled out
<zid>
same with everything else
<heat>
osdev.org ded
<zid>
We've basically been climbing out of third world computer poverty and have.. arrived at the first world.
<heat>
chase chase chase chase chase where are you chase
<zid>
I have storage enough for enough video that I could watch it 24/7
<heat>
thankfully he's always quic- oh wait
<zid>
etc
<heat>
zid host osdev.org with ur xeon
<zid>
my upload is garbo
<heat>
idgaf
<heat>
ask sky for more bandwidth
<zid>
I'd say the uptime would be bad too because I got my voltages wrong and prime95 crashed the machine yesterday, but that'd still be an improvement
<zid>
[17:05] zid is ~zid@pete-14-b2-v4wan-164630-cust398.vm23.cable.virginm.net * zid
<zid>
yes, let's ask sky
<zid>
sky says "Why the fuck are you asking us, we buy it from OpenReach, and you're with virgin media"
<heat>
hi rupert murdoch, why is zid a virgin
<zid>
That should be obvious
<zid>
#osdev
<zid>
and GeDaMo doesn't put out
<GeDaMo>
:|
<heat>
hosting osdev.org on a rpi3 over 3G should be better than being hosted by a fucking ghost
<zid>
GeDaMo: You don't get to pull faces, it's your fault
Bonstra has joined #osdev
<ddevault>
not entirely on-topic, but I reckon this channel knows better than most:
<ddevault>
how can an ELF program on Linux reliably find its ELF header in memory?
<ddevault>
the first PHDR is in the aux vector, and the ELF header *happens* to be at the start of that same page, but that's not a heuristic I'm comfortable relying on
<zid>
link it such that it loads the first byes of itself
<zid>
just a program header with an offset of 0
<ddevault>
right, sure
<ddevault>
I have `text PT_LOAD FILEHDR PHDRS` in the PHDRS section of my linker script
<ddevault>
and I can certainly infer the address space layout from the way my script is written
<ddevault>
but I wonder if there's a better way
<ddevault>
that will work, for example, if a different linker script is used
wand has joined #osdev
<zid>
you don't have to infer anything, elf loader has to do what the phdrs say
<zid>
else the loader is broken
<ddevault>
well, objdump -h actually does not ask for the ELF header to be loaded afaict
<ddevault>
and yet there it is
<ddevault>
not sure what my linker script has to do in order to get GNU ld to produce an appropriate ELF file
<ddevault>
quite aware that if I had-wrote an ELF file I could do whatever I want
<zid>
appropriate for what?
<ddevault>
hand-wrote*
<zid>
I don't think I caught the actual issue
<ddevault>
such that it explicitly requests the ELF header to be loaded, and provides its address to my program
<zid>
you already figured that out though
<ddevault>
I did not -_-
<zid>
yea you did? headers { PT_LOAD FILEHDRS; } or whatever? I think --nmagic or --omagic I forget which also makes binaries in that style if you don't have a linker script to hand
<ddevault>
to put it more clearly: I want to obtain the address of the ELF header, i.e. starting with \x7FELF, in my address space on Linux
<heat>
traditionally it's always at the start of the first program header AFAIK
<heat>
erm,s ection
<heat>
or segment?
<heat>
whatever, you get it
<ddevault>
objdump -p shows the PHDR is correct to load it, so that much is fine
<zid>
yea it helps dynamic linkers to do that
<ddevault>
the ELF file does include it and it is loaded into my address space
<ddevault>
the question is, can I get its address without relying on heuristics
<zid>
I can't find the dynamic linker spec document, can't remember what it's called
<ddevault>
and, now that I talk it through, I think I know how
<zid>
but th environment provides the dynamic linker with a fuck load of info about the incoming file and I wanted to read it :(
wand has quit [Ping timeout: 255 seconds]
<heat>
ddevault, no
<ddevault>
the p_vaddr of the first PHDR should presumably point to the address
xenos1984 has quit [Ping timeout: 255 seconds]
<zid>
but how do you find the phdrs without knowing your own load address? :P
<heat>
iirc linux does (if program header is PHDR, use that, else use load_address + eh_phoff)
wand has joined #osdev
<heat>
the elf header... yeah you'll need to fallback to load_address
<heat>
and hope any segment mapped offset 0
<ddevault>
would be nice if objdump -p actually gave all of the information in the ELF file
<heat>
use readelf
<ddevault>
ty
<heat>
readelf best tool bby
<ddevault>
though now that I do that, the ELF file does /not/ appear correct...
<ddevault>
ah yes it does
<ddevault>
but it's the *second* PHDR that includes the ELF header, not the firstr
<ddevault>
first*
<zid>
heat can you remember what I am talking about
<heat>
zid, sysv abi?
<zid>
maybe lemme see
<zid>
the pdf I just found has like 2 lines for dynamic linking heh, but it's also from 2012