mirror of
https://github.com/ElliotKillick/windows-vs-linux-loader-architecture
synced 2026-06-08 10:57:32 +00:00
Elliot Killick
8f9257c1da
From June to now, most of my time on this project was spent writing "The Rise of Microsoft". Researching and writing that thing took an inordinate amount of time. Also, I took a break to work primarily on another unreleased project I have before switching back to this one. I am proud of what I got here though and I feel like it is all coming together. My plans for the whitepapers are already well drafted and I know they will make an impact. I have learned a ton from working on this project and it has definitely given me something to idly think about and work on in my spare time. Finishing "The Problem with How Windows Uses Threads" was something I thought I wanted done before this release, but oh well. The main README is at about 50K words now, plus all the other smaller documents and you are looking at about a small novel's worth of technical writing. And technical writing takes multiple times longer than typical story writing. Anyway, this project is exciting for me - people who I show it to also really like it - and I am even more excited about what is to come!
46 lines
2.0 KiB
Markdown
46 lines
2.0 KiB
Markdown
# Glibc Debugging Commands
|
|
|
|
These are some helpful debugging tips and commands to aid analysis.
|
|
|
|
## `link_map` Analysis
|
|
|
|
List all library `link_map` structures:
|
|
|
|
```python
|
|
python
|
|
map = int(gdb.parse_and_eval("((struct r_debug *) &_r_debug)->r_map->l_next"))
|
|
while map:
|
|
print(gdb.parse_and_eval(f'((struct link_map *){map})->l_name'))
|
|
map = int(gdb.parse_and_eval(f'((struct link_map *){map})->l_next'))
|
|
```
|
|
|
|
We get a list head from the `r_debug` structure (run `ptype struct r_debug` in GDB to get this structure's definition) then iterate the linear (i.e. non-circular) `link_map` list while printing the library names including their full paths (`l_name`). Notice we skip over the list head immediately by accessing `l_next` before iterating.
|
|
|
|
GDB doesn't have a `!list` macro command like WinDbg, so we use scripting. GDB supports in-line scripting with Python. This is unlike WinDbg where in-line scripting with it's choice language of JavaScript is not possible. A one-liner is not Pythonic and Python's syntax doesn't adapt well to that usage, so we use a short multi-line script (which is more readable anyways, as Python intends) that you can easily copy & paste into your GDB prompt. We choose to frequently run GDB commands with `gdb.parse_and_eval` over using the native Python functions because working with the C-style types is easier.
|
|
|
|
Example Output:
|
|
|
|
```
|
|
0x7ffff7fc7371 "linux-vdso.so.1"
|
|
0x7ffff7fc1080 "/lib64/libc.so.6"
|
|
0x400318 "/lib64/ld-linux-x86-64.so.2"
|
|
0x4052a0 "/home/user/Documents/operating-system-design-review/code/glibc/dlopen/lib1.so"
|
|
0x406610 "/home/user/Documents/operating-system-design-review/code/glibc/dlopen/lib2.so"
|
|
```
|
|
|
|
## Get TCB and Set GSCOPE Watchpoint
|
|
|
|
Read the [thread control block](https://en.wikipedia.org/wiki/Thread_control_block) on GNU/Linux (equivalent to TEB on Windows):
|
|
|
|
```
|
|
set print pretty
|
|
print *(tcbhead_t*)($fs_base)
|
|
```
|
|
|
|
Set a watchpoint on this thread's GSCOPE flag:
|
|
|
|
```
|
|
print &((tcbhead_t*)($fs_base))->gscope_flag
|
|
watch *<OUTPUT_OF_LAST_COMMAND>
|
|
```
|