深入理解GNU调试器GDB内部机制详析

需积分: 3 102 浏览量更新于2024-08-01 收藏 842KB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

《gdbInternals》是一本深入探讨GNU调试器（GDB）内部机制的指南，由John Gilmore撰写，第二版则由Stan Shebs补充和完善。这本书在2004年进行了修订，版权属于Free Software Foundation，遵循GNU自由文档许可证 Version 1.1 或后续版本。本书旨在为读者揭示GDB的核心工作原理，包括但不限于符号表管理、目标代码执行环境、配置细节以及调试算法。第1章概述了文档的范围和目的，强调了对GDB用户和开发者来说的关键信息。它提到了使用本书所需的最低要求，并列出了主要的贡献者名单，体现了开源社区的协作精神。第二部分深入解析了GDB的工作架构。首先，"The Symbol Side"讲述了GDB如何处理和解析源代码中的符号信息，这是调试过程中至关重要的环节，包括符号表的构建和查询。接着，"The Target Side"关注的是与被调试程序（目标程序）交互的部分，涉及汇编语言支持、内存管理和处理器特定的操作。 "Conﬁgurations"章节介绍了GDB的不同配置选项，这些配置影响着调试器的行为和性能，帮助用户根据特定应用场景进行定制。而"Source Tree Structure"部分则展示了GDB的源代码组织结构，这对于理解其内部逻辑和扩展至关重要。第三章详述了GDB的关键算法。"Prologue Analysis"部分讨论了调试器如何分析程序的起始阶段，以便设置恰当的断点和初始化环境。"Breakpoint Handling"着重于断点的设置、触发和撤销机制。"Single Stepping"部分讲解了单步执行的实现，这涉及到控制流跟踪和指令执行的精确性。"Signal Handling"探讨了GDB如何处理程序中的中断和信号，保证调试过程的稳定性和中断响应的正确性。《gdbInternals》是一本技术深度颇高的书籍，对于深入理解GDB内部工作原理，提升调试技能，以及参与GDB的维护和扩展都具有重要价值。通过阅读这本书，读者可以深入了解GDB的每一个核心组件，从而更好地利用这一强大的工具进行程序调试。

资源详情

资源推荐

Chapter 3: Algorithms 9

TARGET_HAS_HARDWARE_WATCHPOINTS

If deﬁned, the target supports hardware watchpoints. (Currently only used for

several native conﬁgs.)

TARGET_CAN_USE_HARDWARE_WATCHPOINT (type, count, other )

Return the number of hardware watchpoints of type type that are possible to

be set. The value is positive if count watchpoints of this type can be set, zero

if setting watchpoints of this type is not supported, and negative if count is

more than the maximum number of watchpoints of type type that can be set.

other is non-zero if other types of watchpoints are currently enabled (there are

architectures which cannot set watchpoints of diﬀerent types at the same time).

TARGET_REGION_OK_FOR_HW_WATCHPOINT (addr, len )

Return non-zero if hardware watchpoints can be used to watch a region whose

address is addr and whose length in bytes is len.

target_insert_watchpoint (addr, len, type )

target_remove_watchpoint (addr, len, type )

Insert or remove a hardware watchpoint s tarting at addr, for len bytes. type

is the watchpoint type, one of the possible values of the enumerated data type

target_hw_bp_type, deﬁned by ‘breakpoint.h’ as follows:

enum target_hw_bp_type

{

hw_write = 0, /* Common (write) HW watchpoint */

hw_read = 1, /* Read HW watchpoint */

hw_access = 2, /* Access (read or write) HW watchpoint */

hw_execute = 3 /* Execute HW breakpoint */

};

These two macros should return 0 for success, non-zero for failure.

target_stopped_data_address (addr_p )

If the inferior has some watchpoint that triggered, place the address associated

with the watchpoint at the location pointed to by addr p and return non-

zero. Otherwise, return zero. This is required for data-read and data-access

watchpoints. It is not required for data-write watchpoints, but gdb uses it to

improve handling of those also.

gdb will only call this method once per watchpoint stop, immediately after

calling STOPPED_BY_WATCHPOINT. If the target’s watchpoint indication is sticky,

i.e., stays set after resuming, this method should clear it. For instance, the x86

debug control register has sticky triggered ﬂags.

target_watchpoint_addr_within_range (target, addr, start, length )

Check whether addr (as returned by target_stopped_data_address) lies

within the hardware-deﬁned watchpoint region described by start and length.

This only needs to be provided if the granularity of a watchpoint is greater

than one byte, i.e., if the watchpoint can also trigger on nearby addresses

outside of the watched region.

HAVE_STEPPABLE_WATCHPOINT

If deﬁned to a non-zero value, it is not necessary to disable a watchpoint to

step over it. Like gdbarch_have_nonsteppable_watchpoint, this is usually set

Chapter 3: Algorithms 10

when watchpoints trigger at the instruction which will pe rform an interesting

read or write. It should be set if there is a temporary disable bit which allows the

processor to step over the interesting instruction without raising the watchpoint

exception again.

int gdbarch_have_nonsteppable_watchpoint (gdbarch )

If it returns a non-zero value, gdb should disable a watchpoint to step the

inferior over it. This is usually set when watchpoints trigger at the instruction

which will perform an interesting read or write.

HAVE_CONTINUABLE_WATCHPOINT

If deﬁned to a non-zero value, it is possible to continue the inferior after a

watchpoint has been hit. This is usually set when watchpoints trigger at the

instruction following an interesting read or write.

CANNOT_STEP_HW_WATCHPOINTS

If this is deﬁned to a non-zero value, gdb will remove all watchpoints before

stepping the inferior.

STOPPED_BY_WATCHPOINT (wait_status )

Return non-zero if stopped by a watchpoint. wait status is of the type struct

target_waitstatus, deﬁned by ‘target.h’. Normally, this macro is deﬁned to

invoke the function pointed to by the to_stopped_by_watchpoint member of

the structure (of the type target_ops, deﬁned on ‘target.h’) that describes the

target-speciﬁc operations; to_stopped_by_watchpoint ignores the wait status

argument.

gdb does not require the non-zero value returned by STOPPED_BY_WATCHPOINT

to be 100% correct, so if a target cannot determine for sure whether the inferior

stopped due to a watchpoint, it could return non-zero “just in case”.

3.8.1 Watchpoints and Threads

gdb only supports process-wide watchpoints, which trigger in all threads. gdb uses the

thread ID to make watchpoints act as if they were thread-speciﬁc, but it cannot set hardware

watchpoints that only trigger in a speciﬁc thread. Therefore, even if the target supports

threads, per-thread debug regis ters, and watchpoints which only aﬀect a single thread, it

should set the per-thread debug registers for all threads to the same value. On gnu/Linux

native targets, this is accomplished by using ALL_LWPS in target_insert_watchpoint and

target_remove_watchpoint and by using linux_set_new_thread to register a handler for

newly created threads.

gdb’s gnu /Linux support only reports a single event at a time, although multiple

events can trigger simultaneously for multi-threaded programs. When multiple events oc-

cur, ‘linux-nat.c’ queues subsequent events and returns them the next time the program is

resumed. This means that STOPPED_BY_WATCHPOINT and target_stopped_data_address

only need to consult the current thread’s state—the thread indicated by inferior_ptid.

If two threads have hit watchpoints simultaneously, those routines will be called a second

time for the second thread.

Chapter 3: Algorithms 11

3.8.2 x86 Watchpoints

The 32-bit Intel x86 (a.k.a. ia32) processors feature special debug registers designed to

facilitate debugging. gdb provides a generic library of functions that x86-based ports

can use to implement support for watchpoints and hardware-assisted breakpoints. This

subsection documents the x86 watchpoint facilities in gdb.

(At present, the library functions read and write debug registers directly, and are thus

only available for native conﬁgurations.)

To use the generic x86 watchpoint support, a port should do the following:

• Deﬁne the mac ro I386_USE_GENERIC_WATCHPOINTS somewhere in the target-dependent

headers.

• Include the ‘config/i386/nm-i386.h’ header ﬁle after deﬁning I386_USE_GENERIC_

WATCHPOINTS.

• Add ‘i386-nat.o’ to the value of the Make variable NATDEPFILES (see Chapter 14

[Native Debugging], page 71).

• Provide implementations for the I386_DR_LOW_* macros described below. Typically,

each macro should call a target-speciﬁc function which does the real work.

The x86 watchpoint support works by maintaining mirror images of the debug registers.

Values are copied between the m irror images and the real debug registers via a set of macros

which each target needs to provide:

I386_DR_LOW_SET_CONTROL (val )

Set the Debug Control (DR7) register to the value val.

I386_DR_LOW_SET_ADDR (idx, addr )

Put the address addr into the debug register number idx.

I386_DR_LOW_RESET_ADDR (idx )

Reset (i.e. zero out) the address stored in the debug register number idx.

I386_DR_LOW_GET_STATUS

Return the value of the Debug Status (DR6) register. This value is used im-

mediately after it is returned by I386_DR_LOW_GET_STATUS, so as to support

per-thread status register values.

For each one of the 4 debug registers (whose indices are from 0 to 3) that store addresses,

a reference count is maintained by gdb, to allow sharing of debug registers by several

watchpoints. This allows users to deﬁne several watchpoints that watch the same expression,

but with diﬀerent conditions and/or commands, without wasting debug registers which are

in short supply. gdb maintains the reference counts internally, targets don’t have to do

anything to use this feature.

The x86 debug registers can each watch a region that is 1, 2, or 4 bytes long. The ia32

architecture requires that each watched region be appropriately aligned: 2-byte region on

2-byte boundary, 4-byte region on 4-byte boundary. However, the x86 watchpoint support

in gdb can watch unaligned regions and regions larger than 4 bytes (up to 16 bytes) by

allocating several debug registers to watch a single region. This allocation of several registers

per a watched region is also done automatically without target code intervention.

The generic x86 watchpoint support provides the following API for the gdb’s application

code:

Chapter 3: Algorithms 12

i386_region_ok_for_watchpoint (addr, len )

The macro TARGET_REGION_OK_FOR_HW_WATCHPOINT is set to call this function.

It counts the number of debug registers required to watch a given region, and

returns a non-zero value if that number is less than 4, the number of debug

registers available to x86 processors.

i386_stopped_data_address (addr_p )

The target function target_stopped_data_address is set to call this function.

This function examines the breakpoint condition bits in the DR6 Debug Status

address associated with the ﬁrst bit that is set in DR6.

i386_stopped_by_watchpoint (void)

The m acro STOPPED_BY_WATCHPOINT is set to call this function. The argu-

ment passed to STOPPED_BY_WATCHPOINT is ignored. This function examines

the breakpoint condition bits in the DR6 Debug Status register, as returned

by the I386_DR_LOW_GET_STATUS macro, and returns true if any bit is set.

Otherwise, false is returned.

i386_insert_watchpoint (addr, len, type )

i386_remove_watchpoint (addr, len, type )

Insert or remove a watchpoint. The macros target_insert_watchpoint and

target_remove_watchpoint are set to call these functions. i386_insert_

watchpoint ﬁrst looks for a debug register which is already set to watch the

same region for the same access types; if found, it just increments the reference

count of that debug register, thus implementing debug register sharing between

watchpoints. If no such register is found, the function looks for a vacant de-

bug register, sets its mirrored value to addr, sets the mirrored value of DR7

Debug Control register as appropriate for the len and type parameters, and

then passes the new values of the debug register and DR7 to the inferior by

calling I386_DR_LOW_SET_ADDR and I386_DR_LOW_SET_CONTROL. If more than

one debug register is required to cover the given region, the above process is

repeated for each debug register.

i386_remove_watchpoint does the opposite: it resets the address in the mir-

rored value of the debug register and its read/write and length bits in the

mirrored value of DR7, then passes these new values to the inferior via I386_

DR_LOW_RESET_ADDR and I386_DR_LOW_SET_CONTROL. If a register is shared by

several watchpoints, each time a i386_remove_watchpoint is called, it decre-

ments the reference count, and only calls I386_DR_LOW_RESET_ADDR and I386_

DR_LOW_SET_CONTROL when the count goes to zero.

i386_insert_hw_breakpoint (bp_tgt )

i386_remove_hw_breakpoint (bp_tgt )

These functions insert and remove hardware-assisted breakpoints. The macros

target_insert_hw_breakpoint and target_remove_hw_breakpoint are set

to call these functions. The argument is a struct bp_target_info *, as de-

scribed in the documentation for target_insert_breakpoint. These func-

tions work like i386_insert_watchpoint and i386_remove_watchpoint, re-

spective ly, except that they set up the debug registers to watch instruction

Chapter 3: Algorithms 13

execution, and each hardware-assisted breakpoint always requires exactly one

debug register.

i386_stopped_by_hwbp (void)

This function returns non-zero if the inferior has some watchpoint or hardware

breakpoint that triggered. It works like i386_stopped_data_address, except

that it doesn’t record the address whose watchpoint triggered.

i386_cleanup_dregs (void)

This function clears all the reference counts, addresses, and control bits in the

mirror images of the debug registers. It doesn’t aﬀect the actual debug registers

in the inferior process.

Notes:

1. x86 processors support setting watchpoints on I/O reads or writes. However, since no

target supports this (as of March 2001), and since enum target_hw_bp_type doesn’t

even have an enumeration for I/O watchpoints, this feature is not yet available to gdb

running on x86.

2. x86 processors can enable watchpoints locally, for the current task only, or globally, for

all the tasks. For each debug register, there’s a bit in the DR7 Debug Control register

that determines whether the associated address is watched locally or globally. The

current implementation of x86 watchpoint support in gdb always sets watchpoints to

be locally enabled, since global watchp oints might interfere with the underlying OS

and are probably unavailable in many platforms.

3.9 Checkpoints

In the abstract, a checkpoint is a point in the execution history of the program, which the

user may wish to return to at some later time.

Internally, a checkpoint is a saved copy of the program state, including whatever infor-

mation is required in order to restore the program to that state at a later time. This can

be expected to include the state of registers and memory, and may include external state

such as the state of open ﬁles and devices.

There are a number of ways in which checkp oints may be implemented in gdb, e.g. as

coreﬁles, as forked processes, and as some opaque method implemented on the target side.

A coreﬁle can be used to save an image of target memory and register state, which can

in principle be restored later — but coreﬁles do not typically include information about

external entities such as open ﬁles. Currently this method is not implemented in gdb.

A forked process can save the state of user memory and registers, as well as some subset

of external (kernel) state. This method is used to implement checkpoints on Linux, and in

principle might be used on other systems.

Some targets, e.g. simulators, might have their own built-in method for saving check-

points, and gdb might be able to take advantage of that capability without neces sarily

knowing any details of how it is done.

剩余126页未读，继续阅读

geshuning

粉丝: 10
资源: 56

深入理解GNU调试器GDB内部机制详析

gdbint.pdf.gz

GDB Internals.pdf

gdb调试pdf

gdb指南.pdf

Sigrity-Clarity3dWorkbench-USB Connector S-parameter Extraction

前端分析-202307110077

常见算法的 C++11 实现片段，适用于算法竞赛.zip

【SCI2区】龙格库塔优化算法RUN-CNN-GRU-Attention用电需求预测Matlab实现.rar

Kaggle竞赛记录.zip

天池入门竞赛.zip

PRCV2021变化检测竞赛第三名解决方案.zip

开学季相关的主题活动，课程介绍，教程内容，推荐资料.m

基于ssm的大学运动场地管理系统设计与实现.docx

BA_produce_tracker-0.0.3-py3-none-any.whl

Kaggle竞赛实战.zip

数学建模竞赛.zip

遥感图像稀疏表征与智能分析竞赛之语义分割.zip

【SCI2区】黑猩猩优化算法Chimp-CNN-GRU-Attention用电需求预测Matlab实现.rar

BAAlgorithmUtils-1.1.2-py3-none-any.whl

AxonDeepSeg-0.4-py2.py3-none-any.whl.zip

最新资源