aboutsummaryrefslogtreecommitdiff
path: root/gdb/python
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@polymtl.ca>2025-03-14 00:32:47 -0400
committerSimon Marchi <simon.marchi@efficios.com>2025-03-14 12:23:38 -0400
commit0bb9d85fc7f86fe5bde091b68facbd72b005c286 (patch)
treef13bfd3d33076fdba5aa248938d02a13580d8f40 /gdb/python
parent5d58950c0d8fbe21051462db7572cba3c9b34a69 (diff)
downloadbinutils-0bb9d85fc7f86fe5bde091b68facbd72b005c286.zip
binutils-0bb9d85fc7f86fe5bde091b68facbd72b005c286.tar.gz
binutils-0bb9d85fc7f86fe5bde091b68facbd72b005c286.tar.bz2
gdb/dwarf: access m_info_ptr directly instead of passing info_ptr around
The few methods of cutu_reader that read DIEs into memory generally receive an info_ptr that says where to start reading and return another one (either by return value or parameter) indicating where the caller should continue reading. We can avoid all this passing around by having these methods access m_info_ptr directly. This allows changing some methods that read DIEs to return `die_info *`, instead of returning it by parameter, which just makes the code simpler to read, I think. The only method that meaningfully reads and writes m_info_ptr (except the places that initially set it up) is read_full_die_1. It reads and increments m_info_ptr once to read the abbrev and once again to read each attribute. Other methods use it for logging. The methods cutu_reader::read_attribute and cutu_reader::read_attribute_value do not touch m_info_ptr directly, because they are used in cooked-indexer.c, which appears to read some things in a non-linear fashion, unlike cutu_reader's DIE-reading methods. The cooked indexer calls cutu_reader::info_ptr to get the m_info_ptr value just after the top-level DIE, and then it does its own attribute reading after that. Change-Id: I251f63d13d453a2827b21349760da033171880e2 Approved-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'gdb/python')
0 files changed, 0 insertions, 0 deletions