diff options
author | Tom Tromey <tom@tromey.com> | 2025-09-14 15:20:25 -0600 |
---|---|---|
committer | Tom Tromey <tom@tromey.com> | 2025-10-05 14:59:01 -0600 |
commit | fe4b853b93f35842c7ec336076236b2891af06e1 (patch) | |
tree | fcc8452e5a9e3d6325587ad39e793d047c9cd006 /gdb/python/py-corefile.c | |
parent | ba597bdd245056667ca3a4ce0dc5264df7a58d80 (diff) | |
download | binutils-fe4b853b93f35842c7ec336076236b2891af06e1.zip binutils-fe4b853b93f35842c7ec336076236b2891af06e1.tar.gz binutils-fe4b853b93f35842c7ec336076236b2891af06e1.tar.bz2 |
Rework domain choices in ctfread.c
Another patch I am working on induced some failures in CTF tests.
Looking into this, I found that ctfread.c seems to largely work by
accident. In particular, it often chooses the wrong domain for a
symbol.
In CTF, I believe there are 4 kinds of symbols: types, variables,
functions, and "data objects" (which IIUC may be either a variable or
a function).
ctfread.c was examining the type-kind of a variable and sometimes
treating one as a type. add_stt_entries and
ctf_psymtab_add_stt_entries only ever used VAR_DOMAIN (but are called
for functions, which should be in FUNCTION_DOMAIN). And
ctf_psymtab_type_cb sometimes used VAR_DOMAIN, but is only called for
types, and so should only ever use TYPE_DOMAIN or STRUCT_DOMAIN.
This patch cleans all this up, based on my understanding of the
situation. This passes the existing tests, and also works with my
aforementioned yet-to-be-submitted patch as well.
Finally, I renamed new_symbol because it is only used for type
symbols.
Acked-By: Simon Marchi <simon.marchi@efficios.com>
Diffstat (limited to 'gdb/python/py-corefile.c')
0 files changed, 0 insertions, 0 deletions