Cross-Platform Development Process (Part 2) – Module 3

0.0(0)
studied byStudied by 0 people
learnLearn
examPractice Test
spaced repetitionSpaced Repetition
heart puzzleMatch
flashcardsFlashcards
Card Sorting

1/29

flashcard set

Earn XP

Description and Tags

Fill-in-the-blank flashcards covering key terms and concepts from the Cross-Platform Development Process (Part 2) lecture: compilers, linkers, ELF structure, memory mapping, testing on target, and system production.

Study Analytics
Name
Mastery
Learn
Test
Matching
Spaced

No study sessions yet.

30 Terms

1
New cards

A is a program that translates source code into machine language (0s and 1s).

Compiler

2
New cards

A translates high-level code like C or C++ into machine code for another device.

Cross Compiler

3
New cards

A translates low-level assembly code on your PC for a different target device.

Cross Assembler

4
New cards

Cross-compiling is useful because the target device is often too _ to build the software itself.

weak / resource-limited

5
New cards

Building one program that runs on phones, tablets, and other devices demonstrates _ development.

cross-platform (portable) development

6
New cards

A puts together all separate object files into one final working program.

Linker

7
New cards

The linker’s job of connecting symbols across files is called .

Symbol Resolution

8
New cards

The linker’s task of adjusting addresses for real memory is called .

Symbol Relocation

9
New cards

A _ Object File is partially compiled and still needs linking.

Relocatable

10
New cards

A _ File is fully linked and ready to run on the target device.

Executable File

11
New cards

A _ Object File holds code that can be shared by multiple programs.

Shared Object File

12
New cards

Using one big file that contains everything a program needs is called .

Static Linking (Stand-alone)

13
New cards

Loading libraries at run-time instead of embedding them is known as .

Dynamic Linking

14
New cards

Before the OS can run a program, a (interpreter) loads it into RAM.

program loader

15
New cards

ELF stands for and _.

Executable and Linking Format

16
New cards

In an ELF file the first part that identifies the file is the .

ELF Header

17
New cards

The _ Header Table tells the OS how to load segments into memory at run-time.

Program

18
New cards

The _ Header Table lists all sections when linking the program.

Section

19
New cards

The _ view of an ELF file is used during compile/link time and sees the file as sections.

Linking View

20
New cards

The _ view of an ELF file is used at run-time and sees the file as segments.

Execution View

21
New cards

Mapping parts of a program into specific areas of RAM is called .

Memory Mapping

22
New cards

Sending the built program from the host to the embedded board is called the to the target.

transferring the executable (file/object)

23
New cards

Running and testing the complete system on the real device is known as on target.

Integrated Testing

24
New cards

Bugs where two operations occur simultaneously causing errors are called .

Race Conditions

25
New cards

In production, developers often switch to cheaper or smaller _ / memory to save cost.

microprocessors

26
New cards

A successful embedded project needs Hardware Engineers, Software Engineers, and _ Engineers.

Systems

27
New cards

Poorly written device _ can cause the entire system to fail during testing.

drivers

28
New cards

A portability issue exists when software runs on one device but _ on another.

won’t work / fails

29
New cards

Ensuring actions happen at the correct moment addresses _ issues.

Timing

30
New cards

The statement “The target device is the computer where the program is written” is _.

FALSE