This PPT discusses the concept of Dynamic Linker as in Linux and its porting to Solaris ARM platform. It starts from the very basics of linking process
FISL XIV - The ELF File Format and the Linux LoaderJohn Tortugo
These are the slides used in a lecture I gave in the XIV International Board on Free Software. In this lecture I gave a brief overview of the ELF specification (the ELF specification is a document describing the format of executable, shared libraries and relocatable objects files used in Linux and many others operating systems) and the Linux dynamic loader (which is a program that acts together with the OS to create and initialize a program address space among others tasks).
FISL XIV - The ELF File Format and the Linux LoaderJohn Tortugo
These are the slides used in a lecture I gave in the XIV International Board on Free Software. In this lecture I gave a brief overview of the ELF specification (the ELF specification is a document describing the format of executable, shared libraries and relocatable objects files used in Linux and many others operating systems) and the Linux dynamic loader (which is a program that acts together with the OS to create and initialize a program address space among others tasks).
GNU Toolchain is the de facto standard of IT industrial and has been improved by comprehensive open source contributions. In this session, it is expected to cover the mechanism of compiler driver, system interaction (take GNU/Linux for example), linker, C runtime library, and the related dynamic linker. Instead of analyzing the system design, the session is use case driven and illustrated progressively.
Virtual File System in Linux Kernel
Note: When you view the the slide deck via web browser, the screenshots may be blurred. You can download and view them offline (Screenshots are clear).
A hands-on introduction to the ELF Object file formatrety61
In our 6th semester we developed miASMa - a 2 pass Macro Assembler for an x86 machine. miASMa generates Relocatable Object Files that conforming to the ELF Format.
Доклад рассказывает об устройстве и опыте применения инструментов динамического тестирования C/C++ программ — AddressSanitizer, ThreadSanitizer и MemorySanitizer. Инструменты находят такие ошибки, как использование памяти после освобождения, обращения за границы массивов и объектов, гонки в многопоточных программах и использования неинициализированной памяти.
A quick tutorial on what debuggers are and how to use them. We present a debugging example using GDB. At the end of this tutorial, you will be able to work your way through a crash and analyze the cause of the error responsible for the crash.
GNU Toolchain is the de facto standard of IT industrial and has been improved by comprehensive open source contributions. In this session, it is expected to cover the mechanism of compiler driver, system interaction (take GNU/Linux for example), linker, C runtime library, and the related dynamic linker. Instead of analyzing the system design, the session is use case driven and illustrated progressively.
Virtual File System in Linux Kernel
Note: When you view the the slide deck via web browser, the screenshots may be blurred. You can download and view them offline (Screenshots are clear).
A hands-on introduction to the ELF Object file formatrety61
In our 6th semester we developed miASMa - a 2 pass Macro Assembler for an x86 machine. miASMa generates Relocatable Object Files that conforming to the ELF Format.
Доклад рассказывает об устройстве и опыте применения инструментов динамического тестирования C/C++ программ — AddressSanitizer, ThreadSanitizer и MemorySanitizer. Инструменты находят такие ошибки, как использование памяти после освобождения, обращения за границы массивов и объектов, гонки в многопоточных программах и использования неинициализированной памяти.
A quick tutorial on what debuggers are and how to use them. We present a debugging example using GDB. At the end of this tutorial, you will be able to work your way through a crash and analyze the cause of the error responsible for the crash.
Debuggers are one of the most important tools in the programmer’s toolkit, but also one of the most overlooked pieces of technology. They have to work in some of the harshest conditions, supporting a huge set of programming languages and aggressive transformations by compilers. What makes them work? And when don’t they work?
In this talk, we will take you on a journey to some of the darkest and most confusing pits of systems programming involving debug formats, compilers and process control. we will describe situations where debuggers have failed you, and why. wef you’re not hacking on debuggers and are not a masochist, you will walk away with an increased appreciation of life.
Sven and I are going to classify Xtext compared to other concepts and frameworks and demonstrate its capabilities with a refined version of an example I presented in London the week before. After that we discuss the versatile possibilities for extending and customizing the framework and finish with an exciting outlook.
C, C++ Training Institute in Chennai , AdyarsasikalaD3
The course fully covers the basics programming in the “C” programming language and demonstrates fundamental programming techniques, custom and vocabulary including the most common library functions and the usage of the processors.
Strategies to improve embedded Linux application performance beyond ordinary ...André Oriani
he common recipe for performance improvement is to profile an application, identify the most time-consuming routines, and finally select them for optimization. Sometimes that is not enough. Developers may have to look inside the OS searching for performance improvement opportunities. Or they might need to optimize code inside a third party library they do not have access to. For those cases, other strategies shall be used. This presentation reports the experiences of Motorola's Brazilian developers reducing the startup time of an application on Motorola's MOTOMAGX embedded Linux platform. Most of the optimization was performed in the binary loading stage, prior to the execution of the entry point function. This endeavor required use of Linux ABI and Linux Loader going beyond typical bottleneck searching. The presentation will cover prelink, dynamic library loading, tuning of shared objects, and enhancing user experience. A live demo will show the use of prelink and other tools to improve performance of general Linux platforms when libraries are used.
Hibernate 3: Hibernate-What it is ?, ORM and Issues, Hibernate Hello World CRUD, Hello world with Servlet, Hibernate Object life cycle, Hibernate Architecture, Object as Component mapping, Hibernate Inheritance, Hibernate Unidirectional Mapping, Hibernate Bidirectional mapping, HQL, Native SQL queries, Named Quarries
Hibernate Query Language (HQL) is an object-oriented query language, similar to SQL, but instead of operating on tables and columns, HQL works with persistent objects and their properties. HQL queries are translated by Hibernate into conventional SQL queries which in turns perform action on database.
Why You Should Replace Windows 11 with Nitrux Linux 3.5.0 for enhanced perfor...SOFTTECHHUB
The choice of an operating system plays a pivotal role in shaping our computing experience. For decades, Microsoft's Windows has dominated the market, offering a familiar and widely adopted platform for personal and professional use. However, as technological advancements continue to push the boundaries of innovation, alternative operating systems have emerged, challenging the status quo and offering users a fresh perspective on computing.
One such alternative that has garnered significant attention and acclaim is Nitrux Linux 3.5.0, a sleek, powerful, and user-friendly Linux distribution that promises to redefine the way we interact with our devices. With its focus on performance, security, and customization, Nitrux Linux presents a compelling case for those seeking to break free from the constraints of proprietary software and embrace the freedom and flexibility of open-source computing.
GraphSummit Singapore | The Art of the Possible with Graph - Q2 2024Neo4j
Neha Bajwa, Vice President of Product Marketing, Neo4j
Join us as we explore breakthrough innovations enabled by interconnected data and AI. Discover firsthand how organizations use relationships in data to uncover contextual insights and solve our most pressing challenges – from optimizing supply chains, detecting fraud, and improving customer experiences to accelerating drug discoveries.
Pushing the limits of ePRTC: 100ns holdover for 100 daysAdtran
At WSTS 2024, Alon Stern explored the topic of parametric holdover and explained how recent research findings can be implemented in real-world PNT networks to achieve 100 nanoseconds of accuracy for up to 100 days.
Communications Mining Series - Zero to Hero - Session 1DianaGray10
This session provides introduction to UiPath Communication Mining, importance and platform overview. You will acquire a good understand of the phases in Communication Mining as we go over the platform with you. Topics covered:
• Communication Mining Overview
• Why is it important?
• How can it help today’s business and the benefits
• Phases in Communication Mining
• Demo on Platform overview
• Q/A
Removing Uninteresting Bytes in Software FuzzingAftab Hussain
Imagine a world where software fuzzing, the process of mutating bytes in test seeds to uncover hidden and erroneous program behaviors, becomes faster and more effective. A lot depends on the initial seeds, which can significantly dictate the trajectory of a fuzzing campaign, particularly in terms of how long it takes to uncover interesting behaviour in your code. We introduce DIAR, a technique designed to speedup fuzzing campaigns by pinpointing and eliminating those uninteresting bytes in the seeds. Picture this: instead of wasting valuable resources on meaningless mutations in large, bloated seeds, DIAR removes the unnecessary bytes, streamlining the entire process.
In this work, we equipped AFL, a popular fuzzer, with DIAR and examined two critical Linux libraries -- Libxml's xmllint, a tool for parsing xml documents, and Binutil's readelf, an essential debugging and security analysis command-line tool used to display detailed information about ELF (Executable and Linkable Format). Our preliminary results show that AFL+DIAR does not only discover new paths more quickly but also achieves higher coverage overall. This work thus showcases how starting with lean and optimized seeds can lead to faster, more comprehensive fuzzing campaigns -- and DIAR helps you find such seeds.
- These are slides of the talk given at IEEE International Conference on Software Testing Verification and Validation Workshop, ICSTW 2022.
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Sudheer Mechineni, Head of Application Frameworks, Standard Chartered Bank
Discover how Standard Chartered Bank harnessed the power of Neo4j to transform complex data access challenges into a dynamic, scalable graph database solution. This keynote will cover their journey from initial adoption to deploying a fully automated, enterprise-grade causal cluster, highlighting key strategies for modelling organisational changes and ensuring robust disaster recovery. Learn how these innovations have not only enhanced Standard Chartered Bank’s data infrastructure but also positioned them as pioneers in the banking sector’s adoption of graph technology.
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
Climate Impact of Software Testing at Nordic Testing DaysKari Kakkonen
My slides at Nordic Testing Days 6.6.2024
Climate impact / sustainability of software testing discussed on the talk. ICT and testing must carry their part of global responsibility to help with the climat warming. We can minimize the carbon footprint but we can also have a carbon handprint, a positive impact on the climate. Quality characteristics can be added with sustainability, and then measured continuously. Test environments can be used less, and in smaller scale and on demand. Test techniques can be used in optimizing or minimizing number of tests. Test automation can be used to speed up testing.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
Dr. Sean Tan, Head of Data Science, Changi Airport Group
Discover how Changi Airport Group (CAG) leverages graph technologies and generative AI to revolutionize their search capabilities. This session delves into the unique search needs of CAG’s diverse passengers and customers, showcasing how graph data structures enhance the accuracy and relevance of AI-generated search results, mitigating the risk of “hallucinations” and improving the overall customer journey.
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
2. Type of Linking
Static Linking : All symbols resolved at the time of linking. For
example, gcc –static flag sets the program to be linked in static
fashion.
Disadvantage : Large program size
Advantage : Fast processing
Dynamic Linking : Symbols are resolved at the time of execution
of the program. gcc by default links the program dynamically.
The program size is small, but the runtime performance cost is
substantial.
2
2009/1/26
3. Example linking process
m.c a.c
Translators Translators
separately compiled
m.o a.o
relocatable object files
Linker (ld)
executable object file
p (contains code and data for all
functions defined in m.c and a.c)
3
2009/1/26
4. What does a linker do?
Merges object files
merges multiple relocatable (.o) object files into a single executable object file
that can loaded and executed by the loader.
Resolves external references
as part of the merging process, resolves external references.
external reference: reference to a symbol defined in another object file.
Relocates symbols
relocates symbols from their relative locations in the .o files to new absolute
positions in the executable.
updates all references to these symbols to reflect their new positions.
references can be in either code or data
code: a(); /* ref to symbol a */
data: int *xp=&x; /* ref to symbol x */
4
2009/1/26
5. Executable and linkable format
(ELF)
Standard binary format for object files
Derives from AT&T System V Unix
later adopted by BSD Unix variants and Linux
One unified format for relocatable object files (.o), executable
object files, and shared object files (.so)
generic name: ELF binaries
Better support for shared libraries than old a.out formats.
5
2009/1/26
6. ELF object file format
Elf header
0
ELF header
magic number, type (.o, exec, .so), machine, byte
Program header table
ordering, etc.
(required for executables)
Program header table
.text section
page size, virtual addresses for memory segments
(sections), segment sizes. .data section
.text section
.bss section
code
.symtab
.data section
.rel.txt
initialized (static) data
.rel.data
.bss section
.debug
uninitialized (static) data
“Block Started by Symbol” Section header table
(required for relocatables)
“Better Save Space”
has section header but occupies no space
6
2009/1/26
7. ELF object file format
.symtab section
symbol table
0
ELF header
procedure and static variable names
Program header table
section names and locations
(required for executables)
.rel.text section
.text section
relocation info for .text section
.data section
addresses of instructions that will need to be
modified in the executable .bss section
instructions for modifying.
.symtab
.rel.data section
.rel.text
relocation info for .data section
.rel.data
addresses of pointer data that will need to be
.debug
modified in the merged executable
.debug section Section header table
(required for relocatables)
info for symbolic debugging (gcc -g)
7
2009/1/26
8. Example C program
m.c a.c
extern int e;
int e=7;
int *ep=&e;
int main() {
int x=15;
int r = a();
int y;
exit(0);
}
int a() {
return *ep+x+y;
}
8
2009/1/26
9. Merging .o files into an executable
Relocatable object files Executable object file
0
.text
system code
headers
.data & .bss
system data system code
main() .text
a()
.text
main()
m.o
more system code
.data
int e = 7
system data
int e = 7 .data
int *ep = &e
.text
a()
int x = 15
.bss
a.o int *ep = &e uninitialized data
.data
int x = 15 .symtab
.bss
int y
.debug
9
2009/1/26
10. Relocating symbols and resolving
external references
Symbols are lexical entities that name functions and variables.
Each symbol has a value (typically a memory address).
Code consists of symbol definitions and references.
References can be either local or external.
m.c a.c
extern int e;
int e=7;
Def of local
symbol e int *ep=&e;
int main() { Ref to
int x=15;
int r = a(); external
int y;
exit(0); symbol e
Def of
}
Defs of
int a() {
local
local
return *ep+x+y;
symbol
Ref to external
symbols x
}
Ref to external ep
symbol exit
and y
(defined in symbol a Def of
Refs of local
libc.so) local
symbols e,x,y
symbol a
10
2009/1/26
11. m.o relocation info
m.c
Disassembly of section .text:
int e=7;
00000000 <main>: 00000000 <main>:
int main() {
0: 55 pushl %ebp
int r = a();
1: 89 e5 movl %esp,%ebp
exit(0); 3: e8 fc ff ff ff call 4 <main+0x4>
} 4: R_386_PC32 a
8: 6a 00 pushl $0x0
a: e8 fc ff ff ff call b <main+0xb>
b: R_386_PC32 exit
f: 90 nop
Disassembly of section .data:
00000000 <e>:
0: 07 00 00 00
source: objdump
11
2009/1/26
12. a.o relocation info (.text)
a.c
Disassembly of section .text:
extern int e;
00000000 <a>:
int *ep=&e;
0: 55 pushl %ebp
int x=15; 1: 8b 15 00 00 00 movl 0x0,%edx
int y; 6: 00
3: R_386_32 ep
int a() { 7: a1 00 00 00 00 movl 0x0,%eax
return *ep+x+y; 8: R_386_32 x
c: 89 e5 movl %esp,%ebp
}
e: 03 02 addl (%edx),%eax
10: 89 ec movl %ebp,%esp
12: 03 05 00 00 00 addl 0x0,%eax
17: 00
14: R_386_32 y
18: 5d popl %ebp
19: c3 ret
12
2009/1/26
13. a.o relocation info (.data)
a.c
Disassembly of section .data:
extern int e;
00000000 <ep>:
int *ep=&e;
0: 00 00 00 00
int x=15; 0: R_386_32 e
int y; 00000004 <x>:
4: 0f 00 00 00
int a() {
return *ep+x+y;
}
13
2009/1/26
15. Executable after relocation and
external reference resolution (.data)
m.c
int e=7;
Disassembly of section .data:
int main() { 0804a010 <__data_start>:
int r = a(); 804a010: 00 00 00 00
exit(0);
0804a014 <p.2>:
}
804a014: f8 a2 04 08
a.c
0804a018 <e>:
extern int e;
804a018: 07 00 00 00
int *ep=&e; 0804a01c <ep>:
int x=15; 804a01c: 18 a0 04 08
int y;
0804a020 <x>:
804a020: 0f 00 00 00
int a() {
return *ep+x+y;
}
15
2009/1/26
16. Strong and weak symbols
Program symbols are either strong or weak
strong: procedures and initialized globals
weak: uninitialized globals
p1.c: p2.c:
weak
strong int foo=5; int foo;
strong
strong p1() { p2() {
} }
16
2009/1/26
17. Static libraries (archives)
p1.c p2.c
Translator Translator
static library (archive) of
p1.o p2.o libc.a
relocatable object files
concatenated into one file.
Linker (ld)
executable object file (only contains code and
p data for libc functions that are called from p1.c
and p2.c)
Further improves modularity and efficiency by packaging
commonly used functions (e.g., C standard library, math library)
Linker selectively includes only the .o files in the archive that are
actually needed by the program.
17
2009/1/26
18. Creating static libraries
atoi.c printf.c random.c
...
Translator Translator Translator
atoi.o printf.o random.o
ar rs libc.a
Archiver (ar)
atoi.o printf.o … random.o
C standard library
libc.a
Archiver allows incremental updates:
• recompile function that changes and replace .o file in archive.
18
2009/1/26
22. Linking process in Solaris
In Solaris/Open Solaris, the linking process is performed in two
steps:
Compile time linking is done by the “ld” tool called the Link
Editor. The link-editor, ld(1), concatenates and interprets data
from one or more input files. These files can be relocatable
objects, shared objects, or archive libraries. From these input
files, one output file is created. This file is either a relocatable
object, an executable application, or a shared object.
The link-editor is most commonly invoked as part of the
compilation environment.
22
2009/1/26
23. Dynamic linker in Solaris
The runtime linker, ld.so.1, processes dynamic executables and
shared objects at runtime, binding the executable and shared
objects together to create a runnable process.
During the link-editing of a dynamic executable, a special .interp
section, together with an associated program header, are created.
This section contains a path name specifying the program’s
interpreter. The default name supplied by the link-editor is the
name of the runtime linker: /usr/lib/ld.so.1 for a 32–bit
executable and /usr/lib/64/ld.so.1 for a 64–bit executable.
The dynamic linker ld.so.1 is itself an ELF shared library. At
program startup, the system maps the ld.so to a part of the
address space and runs its bootstrap code.
23
2009/1/26
24. Link Editor Functions
Following is summary of Link Editor functions:
The concatenation of sections of the same characteristics from the input
relocatable objects to form new sections within the output file. The
concatenated sections can in turn be associated to output segments.
The processing of symbol table information from both relocatable objects
and shared objects to verify and unite references with definitions. The
generation of a new symbol table, or tables, within the output file.
The processing of relocation information from the input relocatable objects,
and the application of this information to the output file by updating other
input sections. In addition, output relocation sections might be generated for
use by the runtime linker.
The generation of program headers that describe all the segments that are
created.
The generation of dynamic linking information sections if necessary, which
provide information such as shared object dependencies and symbol bindings
to the runtime linker.
24
2009/1/26
25. Symbol processing by Link Editor
During input file processing, all local symbols from the input relocatable
objects are passed through to the output file image. All global symbols are
accumulated internally within the link-editor. Each global symbol supplied by a
relocatable object is searched for within this internal symbol table. If a symbol
with the same name has already been encountered from a previous input file,
a symbol resolution process is called. This symbol resolution process
determines which of the two entries are kept.
On completing input file processing, and providing no fatal symbol resolution
errors have occurred, the link-editor determines if any unresolved symbol
references remain. Unresolved symbol references can cause the link-edit to
terminate.
Finally, the link-editor’s internal symbol table is added to the symbol tables of
the image being created.
25
2009/1/26
26. Example
$ cat main.c
extern int u_bar;
extern int u_foo();
int t_bar;
int d_bar = 1;
d_foo()
{
return (u_foo(u_bar, t_bar, d_bar));
}
$ cc -o main.o -c main.c
$ nm -x main.o
[Index] Value Size Type Bind Other Shndx Name
...............
[8] |0x00000000|0x00000000|NOTY |GLOB |0x0 |UNDEF |u_foo
[9] |0x00000000|0x00000040|FUNC |GLOB |0x0 |2 |d_foo
[10] |0x00000004|0x00000004|OBJT |GLOB |0x0 |COMMON |t_bar
[11] |0x00000000|0x00000000|NOTY |GLOB |0x0 |UNDEF |u_bar
[12] |0x00000000|0x00000004|OBJT |GLOB |0x0 |3|d_bar
26
2009/1/26
27. ELF File processing
Sections are the smallest
indivisible units that can be
processed within an ELF file.
Segments are a collection of
sections that represent the
smallest individual units that can
be mapped to a memory image
by the dynamic linker ld.so.
27
2009/1/26
28. Functions of the Dynamic Linker
The runtime linker:
Analyzes the executable’s dynamic information section
(.dynamic) and determines what dependencies are required.
Locates and loads these dependencies, analyzing their dynamic
information sections to determine if any additional
dependencies are required.
Performs any necessary relocations to bind these objects in
preparation for process execution.
Calls any initialization functions provided by the dependencies.
Passes control to the application.
Can be called upon during the application’s execution, to
perform any delayed function binding.
28
2009/1/26
29. ELF Parsing by Dynamic Linker
Executable object file for
example program p
0
ELF header
virtual addr
Process image
Program header table
0x080483e0
(required for executables) init and shared lib
segments
.text section
.data section
0x08048494
.text segment
.bss section
(r/o)
.symtab
.rel.text 0x0804a010
.data segment
.dynamic (initialized r/w)
.debug
0x0804a3b0
Section header table .bss segment
(required for relocatables) (uninitialized r/w)
29
2009/1/26
30. 1. Resolving the Dependencies
When linking a dynamic executable, one or more shared objects
are explicitly referenced. These objects are recorded as
dependencies within the dynamic executable.
The runtime linker uses this dependency information to locate,
and load, the associated objects. These dependencies are
processed in the same order as the dependencies were referenced
during the link-edit of the executable.
Once all the dynamic executable’s dependencies are loaded, each
dependency is inspected, in the order the dependency is loaded,
to locate any additional dependencies. This process continues
until all dependencies are located and loaded. This technique
results in a breadth-first ordering of all dependencies.
30
2009/1/26
31. 1. Resolving the Dependencies
The Solaris runtime linker looks in two default locations for dependencies
/lib and /usr/lib.
The dependencies of a dynamic executable or shared object can be displayed
using ldd. For example, the file /usr/bin/cat has the following dependencies:
$ ldd /usr/bin/cat
libc.so.1 => /lib/libc.so.1
libm.so.2 => /lib/libm.so.2
The dependencies recorded in an object can be inspected using dump. Use
this command to display the file’s .dynamic section, and look for entries that
have a NEEDED tag.
$ dump -Lvp prog
prog:
[INDEX] Tag Value
[1] NEEDED libfoo.so.1
[2] NEEDED libc.so.1
[3] RUNPATH /home/me/lib:/home/you/lib
.........
31
2009/1/26
32. 1. Resolving the Dependencies
The dynamic segment (pointed to by the program header) in the ELF file
contains a pointer to the file's string table (DT_STRTAB) as well as to the
DT_NEEDED entries, each of which contains the offset in the string table
for the name of a required library. The dynamic linker creates a scope list for
the executable, consisting of libraries to be loaded.
For each of the entries in the scope list , the linker searches for the file
containing the library. Once the file is found, the linker reads the ELF Header
to find the program header, which points to the dynamic segment .
The linker maps the library to the process address space. From the dynamic
segment, it adds the library's symbol table to the chain of symbol tables - and
if the libraries has further dependencies, it adds those libraries to the list to be
loaded and the process is continued. For clarification, note that in fact it
actually creates a struct link_map for each of the library and adds it into a
global linked list.
32
2009/1/26
34. Parsing other sections of ELF
For dynamic linking, the Dynamic linker primarily uses two
processor-specific tables, the Global Offset Table (GOT) and
the Procedure Linkage Table (PLT). Dynamic linkers support
PIC Code through the GOT in each shared library.
The GOT contains absolute addresses to all of the static data
referenced in the program. Both the executables that use the
shared libraries and the shared library itself has a PLT. Similar to
how the GOT redirects any position-independent address
calculations to absolute locations, the PLT redirects position-
independent function calls to absolute locations.
34
2009/1/26
35. Parsing other sections of ELF
In the .dynamic section, the important tag types are:
DT_NEEDED: This element holds the string table offset of a
null-terminated string, giving the name of a needed library. The
offset is an index into the table recorded in the DT_STRTAB
entry.
DT_HASH: This element holds the address of the symbol hash
table which refers to the symbol table referenced by the
DT_SYMTAB element.
DT_STRTAB: This element holds the address of the string table.
DT_SYMTAB: This element holds the address of the symbol
table.
35
2009/1/26
36. 2. Relocation Processing
After the runtime linker has loaded all the dependencies required
by an application, the linker processes each object and performs
all necessary relocations.
Relocation is the process of connecting symbolic references with
symbolic definitions. For example, when a program calls a
function, the associated call instruction must transfer control to
the proper destination address at execution. Relocatable files
must have information that describes how to modify their
section contents. This information allows executable and shared
object files to hold the right information for a process’s program
image.
36
2009/1/26
37. 3. Loading segments in memory
The LD_BIND_NOW variable determines the dynamic linking
behavior. If its set, the dynamic linker evaluates the PLT entries,
which is all entries of type R_386_JMP_SLOT, at the load time
itself. Otherwise, the dynamic linker does lazy linking of
procedure addresses and hence the addresses are not bound
unless the routines are called.
37
2009/1/26
38. 4. Delayed Function Binding
Under delayed function binding or lazy loading model, any dependencies that
are labeled for lazy loading are loaded only when explicitly referenced. By
taking advantage of the lazy binding of a function call, the loading of a
dependency is delayed until the function is first referenced. As a result,
objects that are never referenced are never loaded.
As a practical example (.dynamic), shows libdebug.so.1 is marked for lazy
loading. The symbol information section
(.SUNW_syminfo), shows the symbol reference that triggers libdebug.so.1 loading.
$ cc -o prog prog.c -L. -zlazyload -ldebug -znolazyload -lelf -R’$ORIGIN’
$ elfdump -d prog
Dynamic Section: .dynamic
index tag value
[0] POSFLAG_1 0x1 [ LAZY ]
[1] NEEDED 0x123libdebug.so.1
[2] NEEDED 0x131 libelf.so.1
[3] NEEDED 0x13d libc.so.1
38
2009/1/26
39. A look into Solaris runtime linker
The File dl_runtime.c contains the following main routines:
_dl_fixup [Resolves the PLT Symbols]
_dl_profile_fixup
_dl_call_pltexit
Other related routines:
elf_machine_plt_value
elf_machine_fixup_plt
_dl_lookup_symbol_x
39
2009/1/26
40. ARM Specific ELF Header Settings
For ARM target environment, the values in the ELF header are
specifically defined. All other values are as specified in the Tool
Interface Standard Portable Formats Specification:
e_machine is set to EM_ARM (defined as 40)
e_ident[EI_CLASS] is set to ELFCLASS32
e_ident[EI_DATA] is set to:
ELFDATA2LSB for little-endian targets
ELFDATA2MSB for big-endian targets
40
2009/1/26
41. Special sections in ARM ELF Files
In Executable ARM ELF, all Executables have at least two Sections,
unless the linker has been invoked with -nodebug:
The Symbol Table Section:
This Section has the following attributes:
sh_name: quot;.symtabquot;
sh_type: SHT_SYMTAB
sh_addr: 0 (to indicate it is not part of the image)
The String Table Section:
This Section has the following attributes:
sh_name: quot;.strtabquot;
sh_type: SHT_STRTAB
sh_addr: 0 (to indicate it is not part of the image)
41
2009/1/26
42. Special Sections in ARM ELF
Debugging Sections
ARM Executable ELF supports three types of debugging
information held in debugging Sections.
ASD debugging tables
1.
These provide backwards compatibility with ARM's Symbolic Debugger. ASD
debugging information is stored in a single Section in the executable named .asd.
DWARF Version 1.0
2.
DWARF Version 2.0
3.
42
2009/1/26