mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-02-17 13:10:12 +08:00
While looking at build_id_to_bfd_suffix (in gdb/build-id.c) I realised that GDB would likely not do what we wanted if a build-id was ever a single byte. Right now, build-ids generated by the GNU linker are 32 bytes, but there's nothing that forces this to be the case, it's pretty easy to create a fake, single byte, build-id. Given that the build-id is an external input (read from the objfile), GDB should protect itself against these edge cases. The problem with build_id_to_bfd_suffix is that this function creates the path used to lookup either the debug information, or an executable, based on its build-id. So a 3-byte build-id 0xaabbcc will look in the path: `$DEBUG_FILE_DIRECTORY/.build-id/aa/bbcc.debug`. However, a single byte build-id 0xaa, will look in the file: `$DEBUG_FILE_DIRECTORY/.build-id/aa/.debug` which doesn't seem right. Worse, when looking for an objfile given a build-id GDB will look for a file called `$DEBUG_FILE_DIRECTORY/.build-id/aa/` with a trailing '/' character. I propose that, in build_id_to_bfd_suffix we just return early if the build-id is 1 byte (or less) with a return value that indicates no separate file was found. For testing I made use of the DWARF assembler. I needed to update the build-id creation proc, the existing code assumes that the build-id is a multiple of 4 bytes, so I added some additional padding to ensure that the generated note was a multiple of 4 bytes, even if the build-id was not. I added a test with a 1 byte build-id, and also for the case where the build-id has zero length. The zero length case already does what you'd expect (no debug is loaded) as the bfd library rejects the build-id when loading it from the objfile, but adding this additional test is pretty cheap. Approved-By: Kevin Buettner <kevinb@redhat.com>
120 lines
3.7 KiB
Plaintext
120 lines
3.7 KiB
Plaintext
# Copyright 2024 Free Software Foundation, Inc.
|
|
#
|
|
# 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/>.
|
|
|
|
# Create a file with an artificially short (1-byte) build-id, and
|
|
# check that GDB doesn't try to load debug information. If we do try
|
|
# then we end up loading from: `debug-directory/.build-id/xx/.debug`
|
|
# which isn't right.
|
|
|
|
load_lib dwarf.exp
|
|
|
|
# This test can only be run on targets which support DWARF-2 and use gas.
|
|
require dwarf2_support
|
|
|
|
# No remote host testing either.
|
|
require {!is_remote host}
|
|
|
|
standard_testfile main.c
|
|
|
|
# Create an assembler file which encodes BUILDID as the build-id. Compile
|
|
# this along with the global SRCFILE to create a test executable.
|
|
#
|
|
# Split the debug information out from the newly created executable and place
|
|
# it into the debug file directory.
|
|
#
|
|
# Load the executable into GDB and check to see if the debug information was
|
|
# loaded or not. For this test we are expecting that the debug information
|
|
# was not loaded. The reason is that, with short values for BUILDID, GDB ends
|
|
# up looking for the debug information in weird locations.
|
|
proc run_test { buildid } {
|
|
set len [string length $buildid]
|
|
|
|
set asm_file [standard_output_file "$::testfile.$len.S"]
|
|
Dwarf::assemble $asm_file {
|
|
declare_labels int_label int_label2
|
|
|
|
upvar buildid buildid
|
|
|
|
build_id $buildid
|
|
|
|
cu { label cu_start } {
|
|
compile_unit {{language @DW_LANG_C}} {
|
|
int_label2: base_type {
|
|
{name int}
|
|
{byte_size 4 sdata}
|
|
{encoding @DW_ATE_signed}
|
|
}
|
|
|
|
constant {
|
|
{name the_int}
|
|
{type :$int_label2}
|
|
{const_value 99 data1}
|
|
}
|
|
}
|
|
}
|
|
|
|
aranges {} cu_start {
|
|
arange {} 0 0
|
|
}
|
|
}
|
|
|
|
set execfile [standard_output_file $::testfile.$len]
|
|
|
|
if { [build_executable_from_specs "failed to build" \
|
|
$execfile {debug no-build-id} \
|
|
$::srcfile debug \
|
|
$asm_file {}] } {
|
|
return
|
|
}
|
|
|
|
# Create the debug directory.
|
|
set debugdir [standard_output_file "debugdir.$len"]
|
|
set build_id_dir $debugdir/.build-id/$buildid
|
|
remote_exec host "mkdir -p $build_id_dir"
|
|
|
|
# Split out the debug information.
|
|
if {[gdb_gnu_strip_debug $execfile no-debuglink]} {
|
|
unresolved "failed to split out debug information"
|
|
return
|
|
}
|
|
|
|
# Move the debug information into the debug directory. We place the debug
|
|
# information into a file called just '.debug'. GDB should not check this
|
|
# file, but at one point GDB would check this file, even though this
|
|
# doesn't make much sense.
|
|
set execfile_debug ${execfile}.debug
|
|
remote_exec host "mv $execfile_debug $build_id_dir/.debug"
|
|
|
|
# Start GDB, set the debug-file-directory, and try loading the file.
|
|
clean_restart
|
|
|
|
gdb_test_no_output "set debug-file-directory $debugdir" \
|
|
"set debug-file-directory"
|
|
|
|
gdb_file_cmd $execfile
|
|
|
|
gdb_assert { $::gdb_file_cmd_debug_info eq "nodebug" } \
|
|
"no debug should be loaded"
|
|
|
|
# For sanity, read something that was encoded in the debug
|
|
# information, this should fail.
|
|
gdb_test "print the_int" \
|
|
"(?:No symbol table is loaded|No symbol \"the_int\" in current context).*"
|
|
}
|
|
|
|
foreach_with_prefix buildid { a4 "" } {
|
|
run_test $buildid
|
|
}
|