M0nteCarl0/Q&A.txt

## Q&A.txt
Q:
By default, Linux builds user-space programs as dynamically linked applications. Please describe scenarios where you would change the default behavior to compile your application as a statically linked one.
A:
There are several scenarios where you would change the default behavior to compile your application as a statically linked one:

1. Portability: If you want to ensure that your application will run on any system without having to worry about missing shared libraries or different versions of the same libraries, then compiling it statically is a good option.

2. Security: If you want to reduce the attack surface of your application by eliminating the need for external dependencies, then compiling it statically can help improve security.

3. Performance: If your application requires fast startup times and low memory usage, then compiling it statically can provide a performance boost since it eliminates the overhead of dynamic linking.

4. Distribution: If you want to distribute your application as a standalone binary that can be easily installed and run on any system without requiring additional dependencies, then compiling it statically is a good option.

5. Testing: If you want to simplify testing by ensuring that all required libraries are included in the application, then compiling it statically can help streamline the testing process.

Q:
Please explain, at a very high-level, how a Unix OS, such as Linux, implements the break-point feature in a debugger.

A:
In Unix operating systems, including Linux, the break-point feature in a debugger is implemented using the ptrace system call. The ptrace system call allows a debugger process to attach to a running process and control its execution. When a breakpoint is set, the debugger inserts a trap instruction at the specified address in the target process's memory. When the target process executes this instruction, it triggers a trap signal that is intercepted by the debugger. The debugger then suspends the target process and notifies the user that the breakpoint has been hit. The user can then inspect the target process's state and modify its memory before resuming its execution.
Q:
Suppose you debug a Linux application and put a break-point into a function defined by a dynamically-linked library used by the application. Will that break-point stop any other application that makes use of the same library?
A:
No, the breakpoint will only affect the specific instance of the application that is being debugged. Other applications using the same library will not be affected. This is because each instance of a process has its own memory space and execution context, and the debugger is attached only to the specific process that it is debugging.
	Q:
	By default, Linux builds user-space programs as dynamically linked applications. Please describe scenarios where you would change the default behavior to compile your application as a statically linked one.
	A:
	There are several scenarios where you would change the default behavior to compile your application as a statically linked one:

	1. Portability: If you want to ensure that your application will run on any system without having to worry about missing shared libraries or different versions of the same libraries, then compiling it statically is a good option.

	2. Security: If you want to reduce the attack surface of your application by eliminating the need for external dependencies, then compiling it statically can help improve security.

	3. Performance: If your application requires fast startup times and low memory usage, then compiling it statically can provide a performance boost since it eliminates the overhead of dynamic linking.

	4. Distribution: If you want to distribute your application as a standalone binary that can be easily installed and run on any system without requiring additional dependencies, then compiling it statically is a good option.

	5. Testing: If you want to simplify testing by ensuring that all required libraries are included in the application, then compiling it statically can help streamline the testing process.

	Q:
	Please explain, at a very high-level, how a Unix OS, such as Linux, implements the break-point feature in a debugger.

	A:
	In Unix operating systems, including Linux, the break-point feature in a debugger is implemented using the ptrace system call. The ptrace system call allows a debugger process to attach to a running process and control its execution. When a breakpoint is set, the debugger inserts a trap instruction at the specified address in the target process's memory. When the target process executes this instruction, it triggers a trap signal that is intercepted by the debugger. The debugger then suspends the target process and notifies the user that the breakpoint has been hit. The user can then inspect the target process's state and modify its memory before resuming its execution.
	Q:
	Suppose you debug a Linux application and put a break-point into a function defined by a dynamically-linked library used by the application. Will that break-point stop any other application that makes use of the same library?
	A:
	No, the breakpoint will only affect the specific instance of the application that is being debugged. Other applications using the same library will not be affected. This is because each instance of a process has its own memory space and execution context, and the debugger is attached only to the specific process that it is debugging.