aboutsummaryrefslogtreecommitdiff
path: root/gdb/parse.c
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@efficios.com>2022-04-06 10:42:02 -0400
committerSimon Marchi <simon.marchi@polymtl.ca>2022-04-07 13:04:48 -0400
commite4730328287f755eb313c3762d83d389462cde15 (patch)
treed04a2374c079bfb72b3baf745cb15a802137fed4 /gdb/parse.c
parentd3fc98f9117f81fb6473bc2419fbf575e81a9505 (diff)
downloadgdb-e4730328287f755eb313c3762d83d389462cde15.zip
gdb-e4730328287f755eb313c3762d83d389462cde15.tar.gz
gdb-e4730328287f755eb313c3762d83d389462cde15.tar.bz2
gdb: remove symtab::dirname
I think the symtab::dirname method is bogus, or at least very misleading. It makes you think that it returns the directory that was used to find that symtab's file during compilation (i.e. the directory the file refers to in the DWARF line header file table), or the directory part of the symtab's filename maybe. In fact, it returns the compilation unit's directory, which is the CWD of the compiler, at compilation time. At least for DWARF, if the symtab's filename is relative, it will be relative to that directory. But if the symtab's filename is absolute, then the directory returned by symtab::dirname has nothing to do with the symtab's filename. Remove symtab::dirname to avoid this confusion, change all users to fetch the same information through the compunit. At least, it will be clear that this is a compunit property, not a symtab property. Change-Id: I2894c3bf3789d7359a676db3c58be2c10763f5f0
Diffstat (limited to 'gdb/parse.c')
0 files changed, 0 insertions, 0 deletions