Hi, Chris, thanks a lot, i think now i start to understand this indirection, even though what happens in GOT (how the address is replaced to a proper one) is not disclosed. Can you please share the cheat sheet you used?
@Chris Kanich Really amazing video - my favorite so far on TH-cam and trust me I’ve been trying to understand these concepts for some time now 😊 One thing that is still unclear (and has been puzzling me) is how the address 0x400000 is decided as the starting address for the Text Segment. I understand that in the LD Script, the SEGMENT_START is set to 0x400000 for x86 based Linux ELF files, however, what I don’t understand is why (and how) is this address chosen? Is it processor-specific (i.e., does it depends whether it’s an ARM core, or a MIPS core, or an x86 Intel core), and what is stored in between the virtual address 0x0 and the virtual address 0x400000? I learned that the space between 0x0 and 0x400000 is VOID (Read-ONLY) and has been left as such due to historic reasons (such as when the processor had less number of registers). However, it would be awesome if you can throw some light on it. Thanks.
Thanks for the kind comments! 0x400000 is something that the linker decides to use when it generates the ELF executable. In general, it can put whatever sections it wants where it wants in virtual memory. The only restriction it has is that there is a certain offset in the ELF header that indicates the "entry point" - the first line of assembly that the processor should run once the program is loaded. You can look at this by running readelf -h on a fully linked executable - it will show you the header, which includes a pointer to the entry point address.
This is the finest video on GOT, PLT topics. Thanks for your efforts.
thanks for making these lectures public. came here in desire to get a grip on ELF and linking process.
I'm so happy TH-cam recommended your video. Probably the best and most up to date video on the subject. Instant subscribe.
Just WOW... really nice explanation with practical examples
Dude. How do you only have 729 subs. This was so helpful. Thank you very much :)
You jinxed him now he has 4.14k
Great video; the PLT and GOT really confused me until I watched this!
@Chris Kanich I have really enjoyed your videos. This just another in your collection. I always learn a lot from explanations. Thanks.
Hi, great series. I wonder if you have presentations on some kind of repo you could share with others?
The best video on PLT!
can you explain about the GOT and plt in microcontrollers and how this helps in shared libraries in microcontrollers.
So informative! Wanna give 1000 thumbs up
@Chris great video! Do you have another video or can you suggest some resources for understanding how dlopen/dlsym interacts with the GOT and PLT?
Very comprehensive video!
Awesome video! We need more like this on TH-cam!im
Hi, Chris, thanks a lot, i think now i start to understand this indirection, even though what happens in GOT (how the address is replaced to a proper one) is not disclosed. Can you please share the cheat sheet you used?
PERFECT!
@Chris Kanich Really amazing video - my favorite so far on TH-cam and trust me I’ve been trying to understand these concepts for some time now 😊
One thing that is still unclear (and has been puzzling me) is how the address 0x400000 is decided as the starting address for the Text Segment. I understand that in the LD Script, the SEGMENT_START is set to 0x400000 for x86 based Linux ELF files, however, what I don’t understand is why (and how) is this address chosen? Is it processor-specific (i.e., does it depends whether it’s an ARM core, or a MIPS core, or an x86 Intel core), and what is stored in between the virtual address 0x0 and the virtual address 0x400000?
I learned that the space between 0x0 and 0x400000 is VOID (Read-ONLY) and has been left as such due to historic reasons (such as when the processor had less number of registers). However, it would be awesome if you can throw some light on it. Thanks.
Thanks for the kind comments! 0x400000 is something that the linker decides to use when it generates the ELF executable. In general, it can put whatever sections it wants where it wants in virtual memory. The only restriction it has is that there is a certain offset in the ELF header that indicates the "entry point" - the first line of assembly that the processor should run once the program is loaded. You can look at this by running readelf -h on a fully linked executable - it will show you the header, which includes a pointer to the entry point address.
Cool video, please just make black/dark background also for presentation - jumping from black to white in the video really hits eyes... ;)
Great idea, and makes perfect sense! Will change in upcoming videos.
This is like youtube gold
great one......tnx
Great explanation. You saved me :)
Subscribed 🎉
I like your titles
Lazy run-time linking isn't so _lazy_ after all. Huh.