ELF:
Segments in ELF and how it is loaded:
http://www.tenouk.com/Bufferoverflowc/Bufferoverflow1c.html
http://www.kernel.org/doc/man-pages/online/pages/man5/elf.5.html
Segments in ELF and how it is loaded:
http://www.tenouk.com/Bufferoverflowc/Bufferoverflow1c.html
http://www.kernel.org/doc/man-pages/online/pages/man5/elf.5.html
Program headers in an ELF binary describe how the binary should be run. The interesting parts are the LOAD headers which load part of the binary into different places in memory. There could be almost arbitrary number of LOAD headers in a binary, but usually the linker puts everything read-only and executable into one and everything read/write into another. There are operating systems which will have read-only data LOAD header, read-write data and read-only executable code for slightly increased security.
Segments here just mean parts of the binary loaded in different places in memory. So basically the different LOAD headers.
Sections is how the data was organized during linking. For various reasons you want to have better granularity organizing things than just data/code. Some data is read-only, it's put in ".rodata" in your example. The code is in ".text", initialized data is in ".data" while data in variables that are zeroed on program start are in ".bss".
The "section to segment mapping" tells you which sections are in which segments (different LOAD headers). So ".text" and ".rodata" are in the first LOAD header (the third program header) and ".data" is in the second LOAD header (fourth program header).
The stack is something that the operating system gives you on execution and it's not described by an ELF binary.
http://www.linuxjournal.com/article/6463?page=0,0
http://www.linuxjournal.com/article/1060?page=0,0
See also how linker works, to know how loader passes control to linker ld for dynamic linking.
http://www.kernel.org/doc/man-pages/online/pages/man8/ld-linux.so.8.html
http://www.linuxjournal.com/article/1060?page=0,0
See also how linker works, to know how loader passes control to linker ld for dynamic linking.
http://www.kernel.org/doc/man-pages/online/pages/man8/ld-linux.so.8.html
U-Boot:
http://www.scribd.com/doc/56518684/U-Boot-Implementation-Internals
http://www.linux-arm.org/LinuxBootLoader/SMPBoot
http://cache.freescale.com/files/dsp/doc/app_note/AN4173.pdf
DMA:
http://coweb.cc.gatech.edu/sysHackfest/uploads/58/DMA_howto.1.txt
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0424d/index.html
fstab:
SYNOPSIS
#include <fstab.h>
DESCRIPTION
The file fstab contains descriptive information about the various file systems. fstab is only read by programs, and not written; it is the duty of the system administrator to
udev:
DESCRIPTION
udev provides a dynamic device directory containing only the files for actually present devices. It creates or removes device node files in the /dev directory, or it renames
Usually udev runs as udevd(8) and receives uevents directly from the kernel if a device is added or removed from the system.
If udev receives a device event, it matches its configured rules against the available device attributes provided in sysfs to identify the device. Rules that match may provide
http://www.scribd.com/doc/56518684/U-Boot-Implementation-Internals
http://www.linux-arm.org/LinuxBootLoader/SMPBoot
http://cache.freescale.com/files/dsp/doc/app_note/AN4173.pdf
DMA:
http://coweb.cc.gatech.edu/sysHackfest/uploads/58/DMA_howto.1.txt
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0424d/index.html
fstab:
fstab - static information about the filesystems
SYNOPSIS
#include <fstab.h>
DESCRIPTION
The file fstab contains descriptive information about the various file systems. fstab is only read by programs, and not written; it is the duty of the system administrator to
properly create and maintain this file.
udev:
udev - dynamic device management
DESCRIPTION
udev provides a dynamic device directory containing only the files for actually present devices. It creates or removes device node files in the /dev directory, or it renames
network interfaces.
Usually udev runs as udevd(8) and receives uevents directly from the kernel if a device is added or removed from the system.
If udev receives a device event, it matches its configured rules against the available device attributes provided in sysfs to identify the device. Rules that match may provide
additional device information or specify a device node name and multiple symlink names and instruct udev to run additional programs as part of the device event handling.
No comments:
Post a Comment