docs: update README and documentation consistency

Author: swananan

README-zh.md

@@ -15,7 +15,7 @@
     <img src="https://img.shields.io/badge/版本-0.1.0-blue.svg" alt="Version"/>
     <img src="https://img.shields.io/badge/协议-GPL-green.svg" alt="License: GPL"/>
     <img src="https://img.shields.io/badge/Linux-4.4+-orange.svg" alt="Linux 4.4+"/>
-    <img src="https://img.shields.io/badge/Rust-1.75+-red.svg" alt="Rust 1.75+"/>
+    <img src="https://img.shields.io/badge/Rust-1.88.0-red.svg" alt="Rust 1.88.0"/>
   </p>
 
 </div>
@@ -157,7 +157,7 @@ GhostScope 将编译后的二进制文件转变为可观测系统。在函数入
 
 我们欢迎贡献！无论是错误报告、功能请求、文档改进还是代码贡献，我们都感谢您帮助改进 GhostScope。
 
-请查看我们的[贡献指南](docs/contributing.md)了解：
+请查看我们的[贡献指南](docs/zh/contributing.md)了解：
 - 行为准则
 - 开发工作流
 - 编码标准

README.md

@@ -15,7 +15,7 @@
     <img src="https://img.shields.io/badge/version-0.1.0-blue.svg" alt="Version"/>
     <img src="https://img.shields.io/badge/license-GPL-green.svg" alt="License: GPL"/>
     <img src="https://img.shields.io/badge/Linux-4.4+-orange.svg" alt="Linux 4.4+"/>
-    <img src="https://img.shields.io/badge/Rust-1.75+-red.svg" alt="Rust 1.75+"/>
+    <img src="https://img.shields.io/badge/Rust-1.88.0-red.svg" alt="Rust 1.88.0"/>
   </p>
 
   <!-- Language Switch -->

docs/contributing.md

@@ -48,8 +48,3 @@ git commit -m "docs: update installation instructions"
 ## Development Setup
 
 Please refer to the [Development Guide](development.md) for setting up your development environment.
-
-## Community
-
-- [GitHub Discussions](https://github.com/swananan/ghostscope/discussions) - Questions and discussions
-- Email: [email protected]

docs/images/info-line.png

@@ -22,7 +22,7 @@ Currently only supports **Linux** operating system due to its core dependency on
 ## Soft Limitations
 
 ### 1. Language Support
-Currently supports compiled languages (C, C++, Rust) with DWARF debug information. Support for advanced language features is limited, such as Rust async functions and C++ templates, requiring significant effort to improve gradually.
+Primary focus is on **C language**, which has the best support. C++ and Rust are supported with limitations - advanced language features such as Rust async functions and C++ templates have limited support and require significant effort to improve gradually.
 
 For interpreted languages (Lua, Python, Ruby, etc.), only the interpreter itself can be traced (since interpreters are typically implemented in compiled languages). Tracing script code is technically feasible but requires substantial development time. JIT language support is an even more distant goal.
 

docs/limitations.md

@@ -1,9 +1,5 @@
 # GhostScope Roadmap (Milestones)
 
-## Global variables in `-p <pid>` mode — stability and compatibility improvements
-  - Automatic ASLR section offset computation and population
-  - Runtime null-pointer dereference protection
-
 ## Global variables in `-t <exec_path>` mode (planned)
   - Background: resolving globals requires per-module ASLR offsets computed from `/proc/<pid>/maps`, while `-t` mode has no PID context.
   - Direction: introduce PID discovery/subscription in the attach flow, or compute and populate offsets once a PID is known at trigger time; ensure safety and ordering.

docs/roadmap.md

@@ -132,6 +132,21 @@ A more efficient approach is to start from the source panel:
 
 This workflow is more fluid, making trace point setting effortless.
 
+### 💡 Viewing Available Variables at Trace Points
+
+Before setting a trace point, if you want to know which local variables and parameters are accessible at a specific location, you can use the `info` commands:
+
+```
+info line <file:line>       # View available variables at a source line
+info function <func_name>   # View available variables at function entry
+info address <0xADDR>       # View available variables at an address
+```
+
+These commands display debug information for that location, including the list of accessible variables:
+
+![Info Source Line](images/info-line.png)
+*Using info line command to view available variables*
+
 ## Using Script Files
 
 For repeated use, save your traces in a file:

docs/tutorial.md

@@ -22,7 +22,7 @@ eBPF 的 helper 函数不支持处理缺页错误，在读取目标进程的虚
 ## 软性限制
 
 ### 1. 语言支持
-目前主要支持编译型语言（C、C++、Rust）及其生成的 DWARF 调试信息。对于这些语言的高级特性支持有限，例如 Rust 的异步函数、C++ 的模板等，需要投入大量精力逐步完善。
+主要支持 **C 语言**，对 C 的支持最为完善。C++ 和 Rust 是有限支持 - 这些语言的高级特性支持有限，例如 Rust 的异步函数、C++ 的模板等，需要投入大量精力逐步完善。
 
 对于解释型语言（Lua、Python、Ruby 等），目前只能追踪解释器本身（因为解释器通常用编译型语言实现）。追踪脚本代码在技术上可行，但需要大量开发时间，JIT 语言支持计划就更远了。
 

docs/zh/limitations.md

@@ -1,9 +1,5 @@
 # GhostScope 路线图（里程碑）
 
-## 全局变量在 `-p <pid>` 模式下的稳定性与兼容性提升：
-  - ASLR 偏移自动计算与下发
-  - 运行时空指针解引用保护
-
 ## `-t <exec_path>` 模式支持全局变量（计划中）：
   - 背景：全局变量需要结合 `/proc/<pid>/maps` 计算模块偏移，`-t` 启动时尚无 PID 上下文。
   - 方向：在 attach 流程中引入 PID 发现/订阅机制，或在触发时机得到 PID 后再计算并下发偏移；同时确保安全与时序正确。

docs/zh/roadmap.md

@@ -98,6 +98,7 @@ trace {target}  # target 可以是函数或源码行号
 
 #### 3. 命令模式
 这个时候，如果一切顺利，我们将在 eBPF 输出面板上看到脚本对应的输出。但要查看输出，我们需要把焦点切换到 eBPF 输出面板。
+
 ![eBPF Output](../images/ebpf-output.png)
 *eBPF 输出结果*
 
@@ -132,6 +133,22 @@ trace {target}  # target 可以是函数或源码行号
 
 这样的工作流程更加流畅，让追踪点的设置变得轻而易举。
 
+### 💡 查看追踪点可用变量
+
+在设置追踪点之前，如果想知道某个位置可以访问哪些局部变量和参数，可以使用 `info` 命令：
+
+```
+info line <file:line>       # 查看源码行的可用变量
+info function <func_name>   # 查看函数入口的可用变量
+info address <0xADDR>       # 查看地址的可用变量
+```
+
+这些命令会显示该位置的调试信息，包括可访问的变量列表：
+
+![Info Source Line](../images/info-line.png)
+*使用 info line 命令查看可用变量*
+
+
 ## 使用脚本文件
 
 为了重复使用，我们可以将追踪脚本保存在文件中：