系統呼叫lseek和核心file結構體之間的關係
大家都知道lseek就是移動檔案的讀寫位置, 也就是對應核心中file結構體中的某一個變數, 今天就是特別想看一下具體之間的關係.
軟體就在於實踐
首先需要有一個很方便呼叫lseek的環境, 這樣才不會影響我們除錯的興趣, 希望能達到像python, matlab這樣每個函式可以手動跑, 而不像c語言一樣要編寫, 然後編譯, 然後執行, 然後再修改, 編譯. gdb可以
- 先準備檔案1.c, 前面的標頭檔案很重要, 不能漏
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
int main()
{
return 0;
}
gcc 1.c -ggdb3
-ggdb3是為了能方便的使用巨集
gdb ./a.out
b main
r
接下來會使用call open來開啟檔案, 但是如何找到我們將要開啟的檔案在核心中的file結構體的地址呢? kgtp
找到a.out程式號是1138
找到核心do_sys_open原始碼
1012 long do_sys_open(int dfd, const char __user *filename, int flags, umode_t mode)
1013 {
1014 struct open_flags op;
1015 int lookup = build_open_flags(flags, mode, &op);
1016 struct filename *tmp = getname(filename);
1017 int fd = PTR_ERR(tmp);
(gdb)
1018
1019 if (!IS_ERR(tmp)) {
1020 fd = get_unused_fd_flags(flags);
1021 if (fd >= 0) {
1022 struct file *f = do_filp_open(dfd, tmp, &op, lookup);
1023 if (IS_ERR(f)) {
所以要在1023設定tracepoint找到f的值, 並且使用pid 1138來過濾, 總結就是要得到程式1138呼叫do_sys_open的時候的f的值
kgtp命令
tmp=`mktemp`; echo `set pagination off
set confirm off
set circular-trace-buffer on
target remote /sys/kernel/debug/gtp
d
trace open.c:1023
actions
collect f
end
tstart` > $tmp; echo $tmp; cat $tmp; sudo gdb /usr/lib/debug/lib/modules/3.10.0-327.el7.x86_64/vmlinux -x $tmp
`f` has been optimized out, cannot use
但是發現f被優化, 只能找彙編地址來定位f的值
0xffffffff811dd7de <+238>: callq 0xffffffff811efdf0 <do_filp_open>
0xffffffff811dd7e3 <+243>: cmp $0xfffffffffffff000,%rax
所以tracepoint到0xffffffff811dd7e3
kgtp的命令
tmp=`mktemp`; echo `set pagination off
set confirm off
set circular-trace-buffer on
target remote /sys/kernel/debug/gtp
d
trace *0xffffffff811dd7e3 if ((struct task_struct *)$current_task)->pid == 1138
actions
collect $rax
end
tstart` > $tmp; echo $tmp; cat $tmp; sudo gdb /usr/lib/debug/lib/modules/3.10.0-327.el7.x86_64/vmlinux -x $tmp
Tracepoint 1 at 0xffffffff811dd7e3: file fs/open.c, line 1023
回到gdb中手動呼叫call open
(gdb) call open("/root/1.c", O_WRONLY )
$5 = 7
回到kgtp中檢視f的值
(gdb) p/x $rax
$3 = 0xffff88003ad2ee00
(gdb) tfind -1
(gdb) p ((struct file*)$3)->f_pos
$7 = 0
到gdb中call lseek
(gdb) call lseek(7, 1, 0)
$6 = 1
檢視file結構體
p ((struct file*)$3)->f_pos
$9 = 1
到gdb中call lseek
(gdb) call lseek(7, 234, 0)
$7 = 234
檢視file結構體
(gdb) p ((struct file*)$3)->f_pos
$10 = 234
相關文章
- ASM file和file alias之間的對映關係!ASM
- linux之系統命令command和系統呼叫system calls及函式function之間的關係Linux函式Function
- FAILGROUP和REDUNDANCY之間的關係關係!AI
- 體系結構、指令定址、對映關係、系統可靠性
- Oracle資料庫儲存結構之間的關係Oracle資料庫
- 工具和敏捷軟體開發之間的關係敏捷
- tablespace和datafile之間的關係
- 作業系統記憶體管理:頁、頁表項和頁框之間的關係作業系統記憶體
- Window, WindowManager和WindowManagerService之間的關係
- ERP和其他管理軟體之間的邏輯關係
- 理解 virt、res、shr 之間的關係(linux 系統篇)Linux
- 理解virt、res、shr之間的關係(linux系統篇)Linux
- 資料結構與演算法之間有何關係?資料結構演算法
- 類之間的關係
- 黑客和開源革命之間的關係黑客
- 策劃求問:遊戲系統的可玩性和飽和度之間關係的疑問遊戲
- (原)ERP和其他管理軟體之間的邏輯關係
- CPU、記憶體、磁碟IO之間的關係記憶體
- 專案管理中各系統之間的關係專案管理
- 關於RMAN 備份片backup copies 和通道CHANNEL之間關係的總結
- 作業系統核心結構作業系統
- 網站和伺服器之間的關係網站伺服器
- 如何理解Nginx、uWSGI和Flask之間的關係?NginxFlask
- SDK、JDK、JRE 和JVM 之間的關係JDKJVM
- 【java】類之間的關係Java
- Linux 虛擬檔案系統四大物件:超級塊、inode、dentry、file之間關係Linux物件
- ERP和其他管理軟體之間的邏輯關係(原創)
- Fluent API 配置實體和資料庫之間的對映關係API資料庫
- xenomai核心解析之雙核系統呼叫(一)AI
- 一張圖看懂Oracle邏輯結構和物理結構的關係Oracle
- Spring 核心框架體系結構Spring框架
- Java軟體架構設計慨論(轉載)--設計模式和系統架構的關係Java架構設計模式
- 《奔跑吧 Linux核心》之處理器體系結構Linux
- 競拍系統設計和核心資料結構資料結構
- python web下的伺服器結構——WSGI容器、Nginx、Flask之間的關係PythonWeb伺服器NginxFlask
- 探索作業系統:核心、啟動和系統呼叫的奧秘作業系統
- Linux核心學習—— 1核心體系結構Linux
- Web3和元宇宙之間的關係Web元宇宙