/* Support routines for building symbol tables in GDB's internal format.
- Copyright (C) 1986-2020 Free Software Foundation, Inc.
+ Copyright (C) 1986-2021 Free Software Foundation, Inc.
This file is part of GDB.
CORE_ADDR start, CORE_ADDR end,
int is_global, int expandable)
{
- struct gdbarch *gdbarch = get_objfile_arch (m_objfile);
+ struct gdbarch *gdbarch = m_objfile->arch ();
struct pending *next, *next1;
struct block *block;
struct pending_block *pblock;
SYMBOL_BLOCK_VALUE (symbol) = block;
BLOCK_FUNCTION (block) = symbol;
- if (TYPE_NFIELDS (ftype) <= 0)
+ if (ftype->num_fields () <= 0)
{
/* No parameter type information is recorded with the
function's type. Set that from the type of the
}
if (nparams > 0)
{
- TYPE_NFIELDS (ftype) = nparams;
- TYPE_FIELDS (ftype) = (struct field *)
- TYPE_ALLOC (ftype, nparams * sizeof (struct field));
+ ftype->set_num_fields (nparams);
+ ftype->set_fields
+ ((struct field *)
+ TYPE_ALLOC (ftype, nparams * sizeof (struct field)));
iparams = 0;
/* Here we want to directly access the dictionary, because
if (SYMBOL_IS_ARGUMENT (sym))
{
- TYPE_FIELD_TYPE (ftype, iparams) = SYMBOL_TYPE (sym);
+ ftype->field (iparams).set_type (SYMBOL_TYPE (sym));
TYPE_FIELD_ARTIFICIAL (ftype, iparams) = 0;
iparams++;
}
set_last_source_file (name);
/* Default the source language to whatever can be deduced from
- the filename. If nothing can be deduced (such as for a C/C++
- include file with a ".h" extension), then inherit whatever
- language the previous subfile had. This kludgery is
- necessary because there is no standard way in some object
- formats to record the source language. Also, when symtabs
- are allocated we try to deduce a language then as well, but
- it is too late for us to use that information while reading
- symbols, since symtabs aren't allocated until after all the
- symbols have been processed for a given source file. */
+ the filename. If nothing can be deduced (such as for a C/C++
+ include file with a ".h" extension), then inherit whatever
+ language the previous subfile had. This kludgery is
+ necessary because there is no standard way in some object
+ formats to record the source language. Also, when symtabs
+ are allocated we try to deduce a language then as well, but
+ it is too late for us to use that information while reading
+ symbols, since symtabs aren't allocated until after all the
+ symbols have been processed for a given source file. */
subfile->language = deduce_language_from_filename (subfile->name);
if (subfile->language == language_unknown
m_have_line_numbers = true;
}
- if (subfile->line_vector->nitems > 0)
- {
- /* If we have a duplicate for the previous entry then ignore the new
- entry, except, if the new entry is setting the is_stmt flag, then
- ensure the previous entry respects the new setting. */
- e = subfile->line_vector->item + subfile->line_vector->nitems - 1;
- if (e->line == line && e->pc == pc)
- {
- if (is_stmt && !e->is_stmt)
- e->is_stmt = 1;
- return;
- }
- }
-
if (subfile->line_vector->nitems >= subfile->line_vector_length)
{
subfile->line_vector_length *= 2;
* sizeof (struct linetable_entry))));
}
- /* The end of sequence marker is special. We need to reset the
- is_stmt flag on previous lines at the same PC, otherwise these
- lines may cause problems since they might be at the same address
- as the following function. For instance suppose a function calls
- abort there is no reason to emit a ret after that point (no joke).
- So the label may be at the same address where the following
- function begins. A similar problem appears if a label is at the
- same address where an inline function ends we cannot reliably tell
- if this is considered part of the inline function or the calling
- program or even the next inline function, so stack traces may
- give surprising results. Expect gdb.cp/step-and-next-inline.exp
- to fail if these lines are not modified here. */
- if (line == 0 && subfile->line_vector->nitems > 0)
+ /* Normally, we treat lines as unsorted. But the end of sequence
+ marker is special. We sort line markers at the same PC by line
+ number, so end of sequence markers (which have line == 0) appear
+ first. This is right if the marker ends the previous function,
+ and there is no padding before the next function. But it is
+ wrong if the previous line was empty and we are now marking a
+ switch to a different subfile. We must leave the end of sequence
+ marker at the end of this group of lines, not sort the empty line
+ to after the marker. The easiest way to accomplish this is to
+ delete any empty lines from our table, if they are followed by
+ end of sequence markers. All we lose is the ability to set
+ breakpoints at some lines which contain no instructions
+ anyway. */
+ if (line == 0)
{
- e = subfile->line_vector->item + subfile->line_vector->nitems;
- do
+ struct linetable_entry *last = nullptr;
+ while (subfile->line_vector->nitems > 0)
{
- e--;
- if (e->pc != pc || e->line == 0)
+ last = subfile->line_vector->item + subfile->line_vector->nitems - 1;
+ if (last->pc != pc)
break;
- e->is_stmt = 0;
+ subfile->line_vector->nitems--;
}
- while (e > subfile->line_vector->item);
+
+ /* Ignore an end-of-sequence marker marking an empty sequence. */
+ if (last == nullptr || last->line == 0)
+ return;
}
e = subfile->line_vector->item + subfile->line_vector->nitems++;
= [] (const linetable_entry &ln1,
const linetable_entry &ln2) -> bool
{
+ if (ln1.pc == ln2.pc
+ && ((ln1.line == 0) != (ln2.line == 0)))
+ return ln1.line == 0;
+
return (ln1.pc < ln2.pc);
};
projects / binutils-gdb.git / blobdiff