When reading debug info to print an error message, we'll be reading
the debug info off disk, not using edited debug info. sec->rawsize
if non-zero is the correct size.
PR 32663
* dwarf2.c (_bfd_dwarf2_slurp_debug_info): Use
bfd_get_section_limit_octets to properly size debug sections.
Update bfd/dwarf2.c with the post DWARF5 language codes which
were added after DWARF5 was finalized. Adding them makes it
possible to return the mangling style for the new language
codes for Ada 2005 Fortran, C++, C and Assembly.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Jan Beulich <jbeulich@suse.com>
Using a bfd pointer to validate the cache isn't very robust. If a bfd
is closed somehow without clearing the cache, then it's possible that
another bfd is opened using the same memory and thus orig_bfd compares
equal to the new bfd.
* dwarf2.c (struct dwarf2_debug): Add orig_bfd_id. Delete
orig_bfd.
(_bfd_dwarf2_slurp_debug_info): Validate stash with orig_bfd_id.
If a BFD user is making use of a function like
bfd_get_section_contents to read a section into a pre-allocated
buffer, then that BFD user might also want to make use of
_bfd_section_size_insane prior to allocating the buffer they intend to
use in order to validate that the buffer size that plan to allocate is
sane.
This commit makes _bfd_section_size_insane public, by renaming it to
bfd_section_size_insane.
I've updated the existing uses within bfd/, I don't believe this
function is used outside of bfd/ currently.
One place that I plan to make use of this function is in
gdb/gdb_bfd.c, in the function gdb_bfd_get_full_section_contents.
This change isn't included in this commit, but will come later if/when
this has been merged into bfd.
There should be no change in behaviour after this commit.
bfd/
* bfd-in2.h (bfd_section_size_insane): Add declaration.
* compress.c (bfd_get_full_section_contents): Update for new name
of _bfd_section_size_insane.
(bfd_init_section_compress_status): Likewise.
* dwarf2.c (read_section): Likewise.
(_bfd_dwarf2_slurp_debug_info): Likewise.
* libbfd.h (_bfd_section_size_insane): Remove declaration.
* section.c (_bfd_section_size_insane): Rename to ...
(bfd_section_size_insane): ... this.
binutils/
* readelf.c (uncompress_section_contents): Update comment to
account for new name of _bfd_section_size_insane.
Commit 7bd1e04a35 introduced "dwarf2.c:2152:29: runtime error: shift
exponent 64 is too large". This is on the bucket_high_pc calculation
which was moved to the top of insert_arange_in_trie where previously
it was later, at a point where the overflow could not occur. Move it
back and arrange for a duplicate calculation of bucket_high_pc which
is also protected from overflow.
PR 29785
* dwarf2.c (insert_arange_in_trie): Split bucket_high_pc.
Move trie_pc_bits < VMA_BITS into splitting_leaf_will_help.
Pathological cases of dwarf info with overlapping duplicate memory
ranges can cause splitting of trie leaf nodes, which in the worst case
will cause memory to increase without bounds.
PR 29785
* dwarf2.c (insert_arange_in_trie): Don't split leaf nodes
unless that reduces number of elements in at least one node.
Adds two new external authors to etc/update-copyright.py to cover
bfd/ax_tls.m4, and adds gprofng to dirs handled automatically, then
updates copyright messages as follows:
1) Update cgen/utils.scm emitted copyrights.
2) Run "etc/update-copyright.py --this-year" with an extra external
author I haven't committed, 'Kalray SA.', to cover gas testsuite
files (which should have their copyright message removed).
3) Build with --enable-maintainer-mode --enable-cgen-maint=yes.
4) Check out */po/*.pot which we don't update frequently.
bfd/dwarf2.c:read_ranges compares bfd_vma values against -1UL, which
doesn't work correctly when long is 32-bit and bfd_vma is 64-bit
(observed as "nm -l" being very slow for mingw64 host; probably causes
issues on 32-bit hosts as well as IL32LLP64 cases such as mingw64).
Fix by using (bfd_vma) -1 in place of -1UL, as done elsewhere.
Except it isn't out of bounds because space for a larger array has
been allocated.
* dwarf2.c (struct trie_leaf): Make ranges a C99 flexible array.
(alloc_trie_leaf, insert_arange_in_trie): Adjust sizing.
When given two or more DW_AT_call_file for a given function we
currently leak the concat memory.
* dwarf2.c (scan_unit_for_symbols): Don't leak on duplicate
DW_AT_call_file.
PR 30150
* dwarf2.c (comp_unit_contains_address): Renamed to ... (comp_unit_may_contain_address): this,
and added code to return true if the CU's ranges have not yet been computed.
(_bfd_dwarf2_find_nearest_line_with_alt): Use the renamed function, simplifying code in the process.
f.bfd_ptr is set too early to be a reliable indicator of good debug
info.
* dwarf2.c (_bfd_dwarf2_slurp_debug_info): Correct test for
debug info being previously found.
There are failure paths in _bfd_dwarf2_slurp_debug_info that can
result in altered section vmas. Also, when setting ET_REL section
vmas it's not too difficult to handle cases where the original vma was
non-zero, so do that too.
This patch was really in response to an addr2line buffer overflow
processing a fuzzed mips relocatable object file. The file had a
number of .debug_info sections with relocations that included lo16 and
hi16 relocs, and in that order. At least one section VMA was
non-zero. This resulted in processing of DWARF info twice, once via
the call to _bfd_dwarf2_find_nearest_line in
_bfd_mips_elf_find_nearest_line, and because that failed leaving VMAs
altered, the second via the call in _bfd_elf_find_nearest_line. The
first call left entries on mips_hi16_list pointing at buffers
allocated during the first call, the second call processed the
mips_hi16_list after the buffers had been freed. (At least when
running with asan and under valgrind. Under gdb with a non-asan
addr2line the second call allocated exactly the same buffer and the
bug didn't show.) Now I don't really care too much what happens with
fuzzed files, but the logic in _bfd_dwarf2_find_nearest_line is meant
to result in only one read of .debug_info, not multiple reads of the
same info when there are errors. This patch fixes that problem.
* dwarf2.c (struct adjusted_section): Add orig_vma.
(unset_sections): Reset vma to it.
(place_sections): Handle non-zero vma too. Save orig_vma.
(_bfd_dwarf2_slurp_debug_info): Tidy. Correct outdated comment.
On error returns after calling place_sections, call
unset_sections.
(_bfd_dwarf2_find_nearest_line_with_alt): Simplify call to
unset_sections.
This fixes a memory leak in the vanishingly rare cases (found by
fuzzers of course) when something goes wrong in the save_section_vma,
htab_create_alloc or alloc_trie_leaf calls before *pinfo is written.
If *pinfo is not written, _bfd_dwarf2_cleanup_debug_info won't be able
to free that memory.
* dwarf2.c (_bfd_dwarf2_slurp_debug_info): Save stash pointer
on setting up stash.
Another case of fuzzers finding the section size sanity checks are
avoided with SHT_NOBITS sections.
* dwarf2.c (read_section): Check that the DWARF section being
read has contents.
The newer update-copyright.py fixes file encoding too, removing cr/lf
on binutils/bfdtest2.c and ld/testsuite/ld-cygwin/exe-export.exp, and
embedded cr in binutils/testsuite/binutils-all/ar.exp string match.
I think the test for table->files[file].dir being non-zero is wrong
for DWARF5 where index zero is allowed and is the current directory of
the compilation. Most times this will be covered by the use of
table->comp_dir (from DW_AT_comp_dir) in concat_filename but the point
of putting the current dir in .debug_line was so the section could
stand alone without .debug_info.
Also, there is no need to check for table->dirs non-NULL, the
table->num_dirs test is sufficient.
* dwarf2.c (concat_filename): Correct and simplify tests of
directory index.
The testcase in the PR had a variable with both DW_AT_decl_file and
DW_AT_specification, where the DW_AT_specification also specified
DW_AT_decl_file. This leads to a memory leak as the file name is
malloced and duplicates are not expected.
I've also changed find_abstract_instance to not use a temp for "name",
because that can result in a change in behaviour from the usual last
of duplicate attributes wins.
PR 29925
* dwarf2.c (find_abstract_instance): Delete "name" variable.
Free *filename_ptr before assigning new file name.
(scan_unit_for_symbols): Similarly free func->file and
var->file before assigning.
This patch provides a new function to sanity check section sizes.
It's mostly extracted from what we had in bfd_get_full_section_contents
but also handles compressed debug sections.
Improvements are:
- section file offset is taken into account,
- added checks that a compressed section can be read from file.
The function is then used when handling multiple .debug_* sections
that need to be read into a single buffer, to sanity check sizes
before allocating the buffer.
PR 26946, PR 28834
* Makefile.am (LIBBFD_H_FILES): Add section.c.
* compress.c (bfd_get_full_section_contents): Move section size
sanity checks..
* section.c (_bfd_section_size_insane): ..to here. New function.
* dwarf2.c (read_section): Use _bfd_section_size_insane.
(_bfd_dwarf2_slurp_debug_info): Likewise.
* Makefile.in: Regenerate.
* libbfd.h: Regenerate.
The DWARF standard is clear that DW_AT_linkage_name is optional.
Compilers may not provide the attribute on functions and variables,
even though the language mangles names. g++ does not for local
variables and functions. Without DW_AT_linkage_name, mangled object
file symbols can't be directly matched against the source-level
DW_AT_name in DWARF info. One possibility is demangling the object
file symbols, but that comes with its own set of problems:
1) A demangler might not be available for the compiler/language.
2) Demangling doesn't give the source function name as stored in
DW_AT_name. Class and template parameters must be stripped at
least.
So this patch takes a simpler approach. A symbol matches DWARF info
if the DWARF address matches the symbol address, and if the symbol
name contains the DWARF name as a sub-string. Very likely the name
matching is entirely superfluous.
PR 29573
* dwarf.c (lookup_symbol_in_function_table): Match a symbol
containing the DWARF source name as a substring.
(lookup_symbol_in_variable_table): Likewise.
(_bfd_dwarf2_find_nearest_line_with_alt): If stash_find_line_fast
returns false, fall back to comp_unit_find_line.
non_mangled incorrectly returned "true" for Ada. Correct that, and
add a few more non-mangled entries. Return a value suitable for
passing to cplus_demangle to control demangling.
* dwarf2.c: Include demangle.h.
(mangle_style): Rename from non_mangled. Return DMGL_* value
to suit lang. Adjust all callers.
The "sec" field in these structures is only set and used in lookup
functions. It always starts off as NULL. So the only possible effect
of the field is to modify the return of the lookup, which was its
purpose back in 2005 when HJ fixed PR990. Since then we solved the
problem of relocatable object files with the fix for PR2338, so this
field is now redundant.
* dwarf.c (struct funcinfo, struct varinfo): Remove "sec" field.
(lookup_symbol_in_function_table): Don't set or test "sec".
(lookup_symbol_in_variable_table): Likewise.
(info_hash_lookup_funcinfo, info_hash_lookup_varinfo): Likewise.
bfd_find_nearest_line_with_alt functions like bfd_find_nearest_line with
the addition of a parameter for specifying the filename of a supplementary
debug file such as one referenced by .gnu_debugaltlink or .debug_sup.
This patch focuses on implementing bfd_find_nearest_line_with_alt
support for ELF/DWARF2 .gnu_debugaltlink. For other targets this
function simply sets the invalid_operation bfd_error.
PR 29529
* dwarf2.c (struct line_info_table): Add new field:
use_dir_and_file_0.
(concat_filename): Use new field to help select the correct table
slot.
(read_formatted_entries): Do not skip entry 0.
(decode_line_info): Set new field depending upon the version of
DWARF being parsed. Initialise filename based upon the setting of
the new field.
While using perf top for MozillaThunderbird I noticed quite some slow
dissably call with source code involved. E.g.
time ./objdump --start-address=0x0000000004e0dcd0 --stop-address=0x0000000004e0df8b -l -d --no-show-raw-insn -S -C /usr/lib64/thunderbird/libxul.so
took 2.071s and I noticed quite some time is spent in
find_abstract_instance:
33.46% objdump objdump [.] find_abstract_instance
18.22% objdump objdump [.] arange_add
13.77% objdump objdump [.] read_attribute_value
4.82% objdump objdump [.] comp_unit_maybe_decode_line_info
3.10% objdump libc.so.6 [.] __memset_avx2_unaligned_erms
where linked list of CU is iterated when searing for where info_ptr
belongs to:
: 3452 for (u = unit->prev_unit; u != NULL; u = u->prev_unit)
0.00 : 4c61f7: mov 0x10(%rbx),%rax
0.00 : 4c61fb: test %rax,%rax
0.00 : 4c61fe: je 4c6215 <find_abstract_instance+0x365>
: 3453 if (info_ptr >= u->info_ptr_unit && info_ptr < u->end_ptr)
0.00 : 4c6200: cmp 0x60(%rax),%rdx
83.20 : 4c6204: jb 4c620c <find_abstract_instance+0x35c>
0.00 : 4c6206: cmp 0x78(%rax),%rdx
6.89 : 4c620a: jb 4c6270 <find_abstract_instance+0x3c0>
: 3452 for (u = unit->prev_unit; u != NULL; u = u->prev_unit)
0.00 : 4c620c: mov 0x10(%rax),%rax
7.90 : 4c6210: test %rax,%rax
0.00 : 4c6213: jne 4c6200 <find_abstract_instance+0x350>
The following scan can be replaced with search in a splay tree and with
that I can get to 1.5s and there are other symbols where the difference
is even bigger.
bfd/ChangeLog:
PR 29081
* dwarf2.c (struct addr_range): New.
(addr_range_intersects): Likewise.
(splay_tree_compare_addr_range): Likewise.
(splay_tree_free_addr_range): Likewise.
(struct dwarf2_debug_file): Add comp_unit_tree.
(find_abstract_instance): Use the splay tree when searching
for a info_ptr.
(stash_comp_unit): Insert to the splay tree.
(_bfd_dwarf2_cleanup_debug_info): Clean up the splay tree.
The PR23230 testcase uses indexed strings without specifying
SW_AT_str_offsets_base. In this case we left u.str with garbage (from
u.val) which then led to a segfault when attempting to access the
string. Fix that by clearing u.str. The patch also adds missing
sanity checks in the recently committed read_indexed_address and
read_indexed_string functions.
PR 29230
* dwarf2.c (read_indexed_address): Return uint64_t. Sanity check idx.
(read_indexed_string): Use uint64_t for str_offset. Sanity check idx.
(read_attribute_value): Clear u.str for indexed string forms when
DW_AT_str_offsets_base is not yet read or missing.
Since commit b43771b045 it has been possible to look up addresses
that match a unit with errors, since ranges are added to a trie while
the unit is being parsed. On error, parse_comp_unit leaves
first_child_die_ptr NULL which results in a NULL info_ptr being passed
to scan_unit_for_symbols. Fix this by setting unit->error.
Also wrap some overlong lines, and fix some formatting errors.
* dwarf2.c: Formatting.
(parse_comp_unit): Set unit->error on err_exit path.
Requiring C99 means that uses of bfd_uint64_t can be replaced with
uint64_t, and similarly for bfd_int64_t, BFD_HOST_U_64_BIT, and
BFD_HOST_64_BIT. This patch does that, removes #ifdef BFD_HOST_*
and tidies a few places that print 64-bit values.
When using perf to profile large binaries, _bfd_dwarf2_find_nearest_line()
becomes a hotspot, as perf wants to get line number information
(for inline-detection purposes) for each and every sample. In Chromium
in particular (the content_shell binary), this entails going through
475k address ranges, which takes a long time when done repeatedly.
Add a radix-256 trie over the address space to quickly map address to
compilation unit spaces; for content_shell, which is 1.6 GB when some
(but not full) debug information turned is on, we go from 6 ms to
0.006 ms (6 µs) for each lookup from address to compilation unit, a 1000x
speedup.
There is a modest RAM increase of 180 MB in this binary (the existing
linked list over ranges uses about 10 MB, and the entire perf job uses
between 2–3 GB for a medium-size profile); for smaller binaries with few
ranges, there should be hardly any extra RAM usage at all.
PR 28592
PR 15994
PR 15935
* dwarf2.c (lookup_address_in_line_info_table): Return bool rather
than a range.
(comp_unit_find_nearest_line): Likewise. Return true if function
info found without line info.
(_bfd_dwarf2_find_nearest_line): Revert range handling code.
Include the language identifier emitted by gas in the set of ones where
no mangled names are expected. Even if there could be "hand-mangled"
names, gas doesn't emit DW_AT_linkage_name in the first place.
Prior to entering the enclosing "else if()" the earlier associated if()
checks function->is_linkage and, if set, uses function->name. The
comment in patch context precedes (and explains) the setting
function->is_linkage. Yet with the flag set, we should then also return
the function name, just like said earlier if() would do when we came
here a 2nd time for the same "addr". And indeed passing the same address
twice on addr2line's command line would resolve the function for the 2nd
instance, but not for the 1st (if this code path is taken). (This,
obviously, is particularly relevant when there's no ELF symbol table in
the first place, like would be the case - naturally - in PE/COFF
binaries, for example.)
PR 28978
* dwarf2.c (scan_unit_for_symbols): When performing second pass,
check to see if the function or variable being processed is the
same as the previous one.
