binutils-gdb/gdb/buildsym.h
Simon Marchi f71ad5556c gdb: add "id" fields to identify symtabs and subfiles
Printing macros defined in the main source file doesn't work reliably
using various toolchains, especially when DWARF 5 is used.  For example,
using the binaries produced by either of these commands:

    $ gcc --version
    gcc (GCC) 11.2.0
    $ ld --version
    GNU ld (GNU Binutils) 2.38
    $ gcc test.c -g3 -gdwarf-5

    $ clang --version
    clang version 13.0.1
    $ clang test.c -gdwarf-5 -fdebug-macro

I get:

    $ ./gdb -nx -q --data-directory=data-directory a.out
    (gdb) start
    Temporary breakpoint 1 at 0x111d: file test.c, line 6.
    Starting program: /home/simark/build/binutils-gdb-one-target/gdb/a.out

    Temporary breakpoint 1, main () at test.c:6
    6         return ZERO;
    (gdb) p ZERO
    No symbol "ZERO" in current context.

When starting to investigate this (taking the gcc-compiled binary as an
example), we see that GDB fails to look up the appropriate macro scope
when evaluating the expression.  While stopped in
macro_lookup_inclusion:

    (top-gdb) p name
    $1 = 0x62100011a980 "test.c"
    (top-gdb) p source.filename
    $2 = 0x62100011a9a0 "/home/simark/build/binutils-gdb-one-target/gdb/test.c"

`source` is the macro_source_file that we would expect GDB to find.
`name` comes from the symtab::filename field of the symtab we are
stopped in.  GDB doesn't find the appropriate macro_source_file because
the name of the macro_source_file doesn't match exactly the name of the
symtab.

The name of the main symtab comes from the compilation unit's
DW_AT_name, passed to the buildsym_compunit's constructor:

  4815d6125e/gdb/dwarf2/read.c (L10627-10630)

The contents of DW_AT_name, in this case, is "test.c".  It is typically
(what I witnessed all compilers do) the same string that was passed to
the compiler on the command-line.

The name of the macro_source_file comes from the line number program
header's file table, from the call to the line_header::file_file_name
method:

  4815d6125e/gdb/dwarf2/macro.c (L54-65)

line_header::file_file_name prepends the directory path that the file
entry refers to, in the file table (if the file name is not already
absolute).  In this case, the file name is "test.c", appended to the
directory "/home/simark/build/binutils-gdb-one-target/gdb".

Because the symtab's name is not created the same way as the
macro_source_file's name is created, we get this mismatch.  GDB fails to
find the appropriate macro scope for the symtab, and we can't print
macros when stopped in that symtab.

To make this work, we must ensure that paths produced in these two ways
end up identical.  This can be tricky because of the different ways a
path can be passed to the compiler by the user.

Another thing to consider is that while the main symtab's name (or
subfile, before it becomes a symtab) is created using DW_AT_name, the
main symtab is also referred to using its entry in the line table
header's file table, when processing the line table.  We must therefore
ensure that the same name is produced in both cases, so that a call to
"start_subfile" for the main subfile will correctly find the
already-created subfile, created by buildsym_compunit's constructor.  If
we fail to do that, things still often work, because of a fallback: the
watch_main_source_file_lossage method.  This method determines that if
the main subfile has no symbols but there exists another subfile with
the same basename (e.g. "test.c") that does have symbols, it's probably
because there was some filename mismatch.  So it replaces the main
subfile with that other subfile.  I think that heuristic is useful as a
last effort to work around any bug or bad debug info, but I don't think
we should design things such as to rely on it.  It's a heuristic, it can
get things wrong.  So in my search for a fix, it is important that given
some good debug info, we don't end up relying on that for things to
work.

A first attempt at fixing this was to try to prepend the compilation
directory here or not prepend it there.  In practice, because of all the
possible combinations of debug info the compilers produce, it was not
possible to get something that would produce reliable, consistent paths.

Another attempt at fixing this was to make both macro_source_file
objects and symtab objects use the most complete form of path possible.
That means to prepend directories at least until we get an absolute
path.  In theory, we should end up with the same path in all cases.
This generally worked, but because it changed the symtab names, it
resulted in user-visible changes (for example, paths to source files in
Breakpoint hit messages becoming always absolute).  I didn't find this
very good, first because there is a "set filename-display" setting that
lets the user control how they want the paths to be displayed, and that
would suddenly make this setting completely ineffective (although even
today, it is a bit dependent on the debug info).  Second, it would
require a good amount of testsuite tweaks to make tests accept these
suddenly absolute paths.

This new patch is a slight variation of that: it adds a new field called
"filename_for_id" in struct symtab and struct subfile, next to the
existing filename field. The goal is to separate the internal ids used
for finding objects from the names used for presentation.  This field is
used for identifying subfiles, symtabs and macro_source_files
internally.  For DWARF symtabs, this new field is meant to contain the
"most complete possible" path, as discussed above.  So for a given file,
it must always be in the same form, everywhere.  The existing
symtab::filename field remains the one used for printing to the user, so
there shouldn't be any change in how paths are printed.

Changes in the core symtab files are:

 - Add "name_for_id" and "filename_for_id" fields to "struct subfile"
   and "struct symtab", next to existing "name" and "filename" fields.
 - Make buildsym_compunit::buildsym_compunit and
   buildsym_compunit::start_subfile accept a "name_for_id" parameter
   next to the existing "name" ones.
 - Make buildsym_compunit::start_subfile use "name_for_id" for looking
   up existing subfiles.  This is the key thing for making calls
   to start_subfile for the main source file look up the existing
   subfile successfully, and avoid relying on
   watch_main_source_file_lossage.
 - Make sal_macro_scope pass "filename_for_id", rather than "filename",
   to macro_lookup_inclusion.  This is the key thing to making the
   lookup work and macro printing work.

Changes in the DWARF files are:

 - Make line_header::file_file_name return the "most complete possible"
   name.  The only pre-existing user of this method is the macro code,
   to give the macro_source_file objects their name.  And we now want
   them to have this "most complete possible" name, which will match the
   corresponding symtab's "filename_for_id".
 - Make dwarf2_cu::start_compunit_symtab pass the "most complete
   possible" name for the main symtab's "filename_for_id".  In this
   context, where the info comes from the compilation unit's DW_AT_name
   / DW_AT_comp_dir, it means prepending DW_AT_comp_dir to DW_AT_name if
   DW_AT_name is not already absolute.
 - Change dwarf2_start_subfile to build a name_for_id for the subfile
   being started.  The simplest way is to re-use
   line_header::file_file_name, since the callers always have a
   file_entry handy.  This ensures that it will get the exact same path
   representation as the macro code does, for the same file (since it
   also uses line_header::file_file_name).
 - Update calls to allocate_symtab to pass the "name_for_id" from the
   subfile.

Tests exercising all this are added by the following patch.

Of all the cases I tried, the only one I found that ends up relying on
watch_main_source_file_lossage is the following one:

    $ clang --version
    clang version 13.0.1
    Target: x86_64-pc-linux-gnu
    Thread model: posix
    InstalledDir: /usr/bin
    $ clang  ./test.c -g3 -O0 -gdwarf-4
    $ ./gdb -nx --data-directory=data-directory -q -readnow -iex "set debug symtab-create 1"  a.out
    ...
    [symtab-create] start_subfile: name = test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/test.c
    [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c
    [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c
    [symtab-create] start_subfile: found existing symtab with name_for_id /home/simark/build/binutils-gdb-one-target/gdb/./test.c (/home/simark/build/binutils-gdb-one-target/gdb/./test.c)
    [symtab-create] watch_main_source_file_lossage: using subfile ./test.c as the main subfile

As we can see, there are two forms used for "test.c", one with a "." and
one without.  This comes from the fact that the compilation unit DIE
contains:

    DW_AT_name ("test.c")
    DW_AT_comp_dir ("/home/simark/build/binutils-gdb-one-target/gdb")

without a ".", and the line table for that file contains:

    include_directories[  1] = "."
    file_names[  1]:
               name: "test.c"
          dir_index: 1

When assembling the filename from that entry, we get a ".".

It is a bit unexpected that the main filename resulting from the line
table header does not match exactly the name in the compilation unit.
For instance, gcc uses "./test.c" for the DW_AT_name, which gives
identical paths in the compilation unit and in the line table header.

Similarly, with DWARF 5:

    $ clang  ./test.c -g3 -O0 -gdwarf-5

clang create two entries that refer to the same file but are of in a different
form.

    include_directories[  0] = "/home/simark/build/binutils-gdb-one-target/gdb"
    include_directories[  1] = "."
    file_names[  0]:
               name: "test.c"
          dir_index: 0
    file_names[  1]:
               name: "test.c"
          dir_index: 1

The first file name produces a path without a "." while the second does.
This is not caught by watch_main_source_file_lossage, because of
dwarf_decode_lines that creates a symtab for each file entry in the line
table.  It therefore appears as "non-empty" to
watch_main_source_file_lossage.  This results in two symtabs:

    (gdb) maintenance info symtabs
    { objfile /home/simark/build/binutils-gdb-one-target/gdb/a.out ((struct objfile *) 0x613000005d00)
      { ((struct compunit_symtab *) 0x62100011aca0)
        debugformat DWARF 5
        producer clang version 13.0.1
        name test.c
        dirname /home/simark/build/binutils-gdb-one-target/gdb
        blockvector ((struct blockvector *) 0x621000129ec0)
        user ((struct compunit_symtab *) (null))
            { symtab test.c ((struct symtab *) 0x62100011ad20)
              fullname (null)
              linetable ((struct linetable *) 0x0)
            }
            { symtab ./test.c ((struct symtab *) 0x62100011ad60)
              fullname (null)
              linetable ((struct linetable *) 0x621000129ef0)
            }
      }
    }

I am not sure what is the consequence of this, but this is also what
happens before my patch, so I think its acceptable to leave it as-is.

To handle these two cases nicely, I think we will need a function that
removes the unnecessary "." from path names, something that can be done
later.

Finally, I made a change in find_file_and_directory is necessary to
avoid breaking test

    gdb.dwarf2/dw2-compdir-oldgcc.exp: info source gcc42

Without that change, we would get:

    (gdb) info source
    Current source file is /dir/d/dw2-compdir-oldgcc42.S
    Compilation directory is /dir/d

whereas the expected result is:

    (gdb) info source
    Current source file is dw2-compdir-oldgcc42.S
    Compilation directory is /dir/d

This test was added here:

  https://sourceware.org/pipermail/gdb-patches/2012-November/098144.html

Long story short, GCC <= 4.2 apparently had a bug where it would
generate a DW_AT_name with a full path ("/dir/d/dw2-compdir-oldgcc42.S")
and no DW_AT_comp_dir.  The line table has one entry with filename
"dw2-compdir-oldgcc42.S", which refers to directory 0.  Directory 0
normally refers to the compilation unit's comp dir, but it is
non-existent in this case.

This caused some symtab lookup problems, and to work around them, some
workaround was added, which today reads as:

    if (res.get_comp_dir () == nullptr
        && producer_is_gcc_lt_4_3 (cu)
        && res.get_name () != nullptr
        && IS_ABSOLUTE_PATH (res.get_name ()))
      res.set_comp_dir (ldirname (res.get_name ()));

Source: 6577f365eb/gdb/dwarf2/read.c (L9428-9432)

It extracts an artificial DW_AT_comp_dir from DW_AT_name, if there is no
DW_AT_comp_dir and DW_AT_name is absolute.

Prior to my patch, a subfile would get created with filename
"/dir/d/dw2-compdir-oldgcc42.S", from DW_AT_name, and another would get
created with filename "dw2-compdir-oldgcc42.S" from the line table's
file table.  Then watch_main_source_file_lossage would kick in and merge
them, keeping only the "dw2-compdir-oldgcc42.S" one:

    [symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S
    [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S
    [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S
    [symtab-create] start_subfile: found existing symtab with name dw2-compdir-oldgcc42.S (dw2-compdir-oldgcc42.S)
    [symtab-create] watch_main_source_file_lossage: using subfile dw2-compdir-oldgcc42.S as the main subfile

And so "info source" would show "dw2-compdir-oldgcc42.S" as the
filename.

With my patch applied, but without the change in
find_file_and_directory, both DW_AT_name and the line table would try to
start a subfile with the same filename_for_id, and there was no need for
watch_main_source_file_lossage - which is what we want:

[symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S
[symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S
[symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S)
[symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S
[symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S)

But since the one with name == "/dir/d/dw2-compdir-oldgcc42.S", coming
from DW_AT_name, gets created first, it wins, and the symtab ends up
with "/dir/d/dw2-compdir-oldgcc42.S" as the name, "info source" shows
"/dir/d/dw2-compdir-oldgcc42.S" and the test breaks.

This is not wrong per-se, after all DW_AT_name is
"/dir/d/dw2-compdir-oldgcc42.S", so it wouldn't be wrong to report the
current source file as "/dir/d/dw2-compdir-oldgcc42.S".  If you compile
a file passing "/an/absolute/path.c", DW_AT_name typically contains (at
least with GCC) "/an/absolute/path.c" and GDB tells you that the source
file is "/an/absolute/path.c".  But we can also keep the existing
behavior fairly easily with a little change in find_file_and_directory.
When extracting an artificial DW_AT_comp_dir from DW_AT_name, we now
modify the name to just keep the file part.  The result is coherent with
what compilers do when you compile a file by just passing its filename
("gcc path.c -g"):

      DW_AT_name        ("path.c")
      DW_AT_comp_dir    ("/home/simark/build/binutils-gdb-one-target/gdb")

With this change, filename_for_id is still the full name,
"/dir/d/dw2-compdir-oldgcc42.S", but the filename of the subfile /
symtab (what ends up shown by "info source") is just
"dw2-compdir-oldgcc42.S", and that makes the test happy.

Change-Id: I8b5cc4bb3052afdb172ee815c051187290566307
2022-07-29 20:54:49 -04:00

458 lines
13 KiB
C++
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

/* Build symbol tables in GDB's internal format.
Copyright (C) 1986-2022 Free Software Foundation, Inc.
This file is part of GDB.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
#if !defined (BUILDSYM_H)
#define BUILDSYM_H 1
#include "gdbsupport/gdb_obstack.h"
#include "symtab.h"
#include "addrmap.h"
struct objfile;
struct symbol;
struct addrmap;
struct compunit_symtab;
enum language;
/* This module provides definitions used for creating and adding to
the symbol table. These routines are called from various symbol-
file-reading routines.
They originated in dbxread.c of gdb-4.2, and were split out to
make xcoffread.c more maintainable by sharing code. */
struct block;
struct pending_block;
struct dynamic_prop;
/* The list of sub-source-files within the current individual
compilation. Each file gets its own symtab with its own linetable
and associated info, but they all share one blockvector. */
struct subfile
{
subfile () = default;
/* There's nothing wrong with copying a subfile, but we don't need to, so use
this to avoid copying one by mistake. */
DISABLE_COPY_AND_ASSIGN (subfile);
struct subfile *next = nullptr;
std::string name;
/* This field is analoguous in function to symtab::filename_for_id.
It is used to look up existing subfiles in calls to start_subfile. */
std::string name_for_id;
std::vector<linetable_entry> line_vector_entries;
enum language language = language_unknown;
struct symtab *symtab = nullptr;
};
using subfile_up = std::unique_ptr<subfile>;
/* Record the symbols defined for each context in a list. We don't
create a struct block for the context until we know how long to
make it. */
#define PENDINGSIZE 100
struct pending
{
struct pending *next;
int nsyms;
struct symbol *symbol[PENDINGSIZE];
};
/* Stack representing unclosed lexical contexts (that will become
blocks, eventually). */
struct context_stack
{
/* Outer locals at the time we entered */
struct pending *locals;
/* Pending using directives at the time we entered. */
struct using_direct *local_using_directives;
/* Pointer into blocklist as of entry */
struct pending_block *old_blocks;
/* Name of function, if any, defining context */
struct symbol *name;
/* Expression that computes the frame base of the lexically enclosing
function, if any. NULL otherwise. */
struct dynamic_prop *static_link;
/* PC where this context starts */
CORE_ADDR start_addr;
/* Temp slot for exception handling. */
CORE_ADDR end_addr;
/* For error-checking matching push/pop */
int depth;
};
/* Flags associated with a linetable entry. */
enum linetable_entry_flag : unsigned
{
/* Indicates this PC is a good location to place a breakpoint at LINE. */
LEF_IS_STMT = 1 << 1,
/* Indicates this PC is a good location to place a breakpoint at the first
instruction past a function prologue. */
LEF_PROLOGUE_END = 1 << 2,
};
DEF_ENUM_FLAGS_TYPE (enum linetable_entry_flag, linetable_entry_flags);
/* Buildsym's counterpart to struct compunit_symtab. */
struct buildsym_compunit
{
/* Start recording information about a primary source file (IOW, not an
included source file).
COMP_DIR is the directory in which the compilation unit was compiled
(or NULL if not known).
NAME and NAME_FOR_ID have the same purpose as for the start_subfile
method. */
buildsym_compunit (struct objfile *objfile_, const char *name,
const char *comp_dir_, const char *name_for_id,
enum language language_, CORE_ADDR last_addr);
/* Same as above, but passes NAME for NAME_FOR_ID. */
buildsym_compunit (struct objfile *objfile_, const char *name,
const char *comp_dir_, enum language language_,
CORE_ADDR last_addr)
: buildsym_compunit (objfile_, name, comp_dir_, name, language_, last_addr)
{}
/* Reopen an existing compunit_symtab so that additional symbols can
be added to it. Arguments are as for the main constructor. CUST
is the expandable compunit_symtab to be reopened. */
buildsym_compunit (struct objfile *objfile_, const char *name,
const char *comp_dir_, enum language language_,
CORE_ADDR last_addr, struct compunit_symtab *cust)
: m_objfile (objfile_),
m_last_source_file (name == nullptr ? nullptr : xstrdup (name)),
m_comp_dir (comp_dir_ == nullptr ? "" : comp_dir_),
m_compunit_symtab (cust),
m_language (language_),
m_last_source_start_addr (last_addr)
{
}
~buildsym_compunit ();
DISABLE_COPY_AND_ASSIGN (buildsym_compunit);
void set_last_source_file (const char *name)
{
char *new_name = name == NULL ? NULL : xstrdup (name);
m_last_source_file.reset (new_name);
}
const char *get_last_source_file ()
{
return m_last_source_file.get ();
}
struct macro_table *get_macro_table ();
struct macro_table *release_macros ()
{
struct macro_table *result = m_pending_macros;
m_pending_macros = nullptr;
return result;
}
/* This function is called to discard any pending blocks. */
void free_pending_blocks ()
{
m_pending_block_obstack.clear ();
m_pending_blocks = nullptr;
}
struct block *finish_block (struct symbol *symbol,
struct pending_block *old_blocks,
const struct dynamic_prop *static_link,
CORE_ADDR start, CORE_ADDR end);
void record_block_range (struct block *block,
CORE_ADDR start, CORE_ADDR end_inclusive);
/* Start recording information about source code that comes from a source
file. This sets the current subfile, creating it if necessary.
NAME is the user-visible name of the subfile.
NAME_FOR_ID is a name that must be stable between the different calls to
start_subfile referring to the same file (it is used for looking up
existing subfiles). It can be equal to NAME if NAME follows that rule. */
void start_subfile (const char *name, const char *name_for_id);
/* Same as above, but passes NAME for NAME_FOR_ID. */
void start_subfile (const char *name)
{
return start_subfile (name, name);
}
void patch_subfile_names (struct subfile *subfile, const char *name);
void push_subfile ();
const char *pop_subfile ();
void record_line (struct subfile *subfile, int line, CORE_ADDR pc,
linetable_entry_flags flags);
struct compunit_symtab *get_compunit_symtab ()
{
return m_compunit_symtab;
}
void set_last_source_start_addr (CORE_ADDR addr)
{
m_last_source_start_addr = addr;
}
CORE_ADDR get_last_source_start_addr ()
{
return m_last_source_start_addr;
}
struct using_direct **get_local_using_directives ()
{
return &m_local_using_directives;
}
void set_local_using_directives (struct using_direct *new_local)
{
m_local_using_directives = new_local;
}
struct using_direct **get_global_using_directives ()
{
return &m_global_using_directives;
}
bool outermost_context_p () const
{
return m_context_stack.empty ();
}
struct context_stack *get_current_context_stack ()
{
if (m_context_stack.empty ())
return nullptr;
return &m_context_stack.back ();
}
int get_context_stack_depth () const
{
return m_context_stack.size ();
}
struct subfile *get_current_subfile ()
{
return m_current_subfile;
}
struct pending **get_local_symbols ()
{
return &m_local_symbols;
}
struct pending **get_file_symbols ()
{
return &m_file_symbols;
}
struct pending **get_global_symbols ()
{
return &m_global_symbols;
}
void record_debugformat (const char *format)
{
m_debugformat = format;
}
void record_producer (const char *producer)
{
m_producer = producer;
}
struct context_stack *push_context (int desc, CORE_ADDR valu);
struct context_stack pop_context ();
struct block *end_compunit_symtab_get_static_block
(CORE_ADDR end_addr, int expandable, int required);
struct compunit_symtab *end_compunit_symtab_from_static_block
(struct block *static_block, int section, int expandable);
struct compunit_symtab *end_compunit_symtab (CORE_ADDR end_addr, int section);
struct compunit_symtab *end_expandable_symtab (CORE_ADDR end_addr,
int section);
void augment_type_symtab ();
private:
void record_pending_block (struct block *block, struct pending_block *opblock);
struct block *finish_block_internal (struct symbol *symbol,
struct pending **listhead,
struct pending_block *old_blocks,
const struct dynamic_prop *static_link,
CORE_ADDR start, CORE_ADDR end,
int is_global, int expandable);
struct blockvector *make_blockvector ();
void watch_main_source_file_lossage ();
struct compunit_symtab *end_compunit_symtab_with_blockvector
(struct block *static_block, int section, int expandable);
/* The objfile we're reading debug info from. */
struct objfile *m_objfile;
/* List of subfiles (source files).
Files are added to the front of the list.
This is important mostly for the language determination hacks we use,
which iterate over previously added files. */
struct subfile *m_subfiles = nullptr;
/* The subfile of the main source file. */
struct subfile *m_main_subfile = nullptr;
/* Name of source file whose symbol data we are now processing. This
comes from a symbol of type N_SO for stabs. For DWARF it comes
from the DW_AT_name attribute of a DW_TAG_compile_unit DIE. */
gdb::unique_xmalloc_ptr<char> m_last_source_file;
/* E.g., DW_AT_comp_dir if DWARF. Space for this is malloc'd. */
std::string m_comp_dir;
/* Space for this is not malloc'd, and is assumed to have at least
the same lifetime as objfile. */
const char *m_producer = nullptr;
/* Space for this is not malloc'd, and is assumed to have at least
the same lifetime as objfile. */
const char *m_debugformat = nullptr;
/* The compunit we are building. */
struct compunit_symtab *m_compunit_symtab = nullptr;
/* Language of this compunit_symtab. */
enum language m_language;
/* The macro table for the compilation unit whose symbols we're
currently reading. */
struct macro_table *m_pending_macros = nullptr;
/* True if symtab has line number info. This prevents an otherwise
empty symtab from being tossed. */
bool m_have_line_numbers = false;
/* Core address of start of text of current source file. This too
comes from the N_SO symbol. For Dwarf it typically comes from the
DW_AT_low_pc attribute of a DW_TAG_compile_unit DIE. */
CORE_ADDR m_last_source_start_addr;
/* Stack of subfile names. */
std::vector<const char *> m_subfile_stack;
/* The "using" directives local to lexical context. */
struct using_direct *m_local_using_directives = nullptr;
/* Global "using" directives. */
struct using_direct *m_global_using_directives = nullptr;
/* The stack of contexts that are pushed by push_context and popped
by pop_context. */
std::vector<struct context_stack> m_context_stack;
struct subfile *m_current_subfile = nullptr;
/* The mutable address map for the compilation unit whose symbols
we're currently reading. The symtabs' shared blockvector will
point to a fixed copy of this. */
struct addrmap_mutable m_pending_addrmap;
/* True if we recorded any ranges in the addrmap that are different
from those in the blockvector already. We set this to false when
we start processing a symfile, and if it's still false at the
end, then we just toss the addrmap. */
bool m_pending_addrmap_interesting = false;
/* An obstack used for allocating pending blocks. */
auto_obstack m_pending_block_obstack;
/* Pointer to the head of a linked list of symbol blocks which have
already been finalized (lexical contexts already closed) and which
are just waiting to be built into a blockvector when finalizing the
associated symtab. */
struct pending_block *m_pending_blocks = nullptr;
/* Pending static symbols and types at the top level. */
struct pending *m_file_symbols = nullptr;
/* Pending global functions and variables. */
struct pending *m_global_symbols = nullptr;
/* Pending symbols that are local to the lexical context. */
struct pending *m_local_symbols = nullptr;
};
extern void add_symbol_to_list (struct symbol *symbol,
struct pending **listhead);
extern struct symbol *find_symbol_in_list (struct pending *list,
char *name, int length);
#endif /* defined (BUILDSYM_H) */