I tried gdbreplay yesterday, but the remotelogfile I received was made
on Windows, so the lines were terminated with \r\n rather than plain
\n.
This patch changes gdbreplay to allow \r\n line termination when
reading the log file.
gdb/gdbserver/ChangeLog
2019-02-27 Tom Tromey <tromey@adacore.com>
* gdbreplay.c (logchar): Handle \r\n.
As a follow up to the previous commit, add a test for "set
width/height -1", to make sure we don't overflow in readline with
negative values either.
gdb/testsuite/ChangeLog:
2019-02-27 Pedro Alves <palves@redhat.com>
* gdb.base/page.exp: Add tests for "set width/height -1".
When we cap the height/width sizes before passing to readline, tweak
the corresponding command variable to show "unlimited":
(gdb) set height 0x8000
(gdb) show height
Number of lines gdb thinks are in a page is unlimited.
Instead of the current output:
(gdb) set height 0x8000
(gdb) show height
Number of lines gdb thinks are in a page is 32768.
gdb/ChangeLog:
2019-02-27 Pedro Alves <palves@redhat.com>
* utils.c (set_screen_size): When we cap the height/width sizes,
tweak the corresponding command variable to show "unlimited":
gdb/testsuite/ChangeLog:
2019-02-27 Pedro Alves <palves@redhat.com>
* gdb.base/page.exp: Add tests for "set/show width/height" with
"infinite" values.
GDB calls rl_set_screen_size in readline with the current screen size,
measured in rows and columns. To represent "infinite" sizes, GDB
passes in INT_MAX; however, since rl_set_screen_size internally
multiplies the number of rows and columns, this causes a signed
integer overflow. To prevent this we can instead pass in the
approximate square root of INT_MAX (which is still reasonably large),
so that even when the number of rows and columns is "infinite" we
don't overflow.
gdb/ChangeLog:
2019-02-27 Saagar Jha <saagar@saagarjha.com>
Pedro Alves <palves@redhat.com>
* utils.c (set_screen_size): Reduce "infinite" rows and columns
before calling rl_set_screen_size.
This patch removes the non-IS_PY3K code in infpy_write_memory()
and infpy_search_memory(). In both cases, the remaining code
from these ifdefs is related to use of the PEP 3118 buffer protocol.
(Deleted code is either due to simplification or related to use of the
old buffer protocol.) PEP 3118 is sometimes referred to as the "new"
buffer protocol, though it's not that new anymore.
The link below describes new features in Python 2.6. In particular,
it says that the buffer protocol described by PEP 3118 is in Python
2.6. It also says (at the top of the page) that Python 2.6 was
released on Oct 1, 2008.
https://docs.python.org/3/whatsnew/2.6.html#pep-3118-revised-buffer-protocol
The last security release for the Python 2.6 series was 2.6.9. It was
released on Oct 29, 2013. According to this document...
https://www.python.org/download/releases/2.6.9/
...support for the 2.6 series has ended:
With the 2.6.9 release, and five years after its first release,
the Python 2.6 series is now officially retired. All official
maintenance for Python 2.6, including security patches, has ended.
For ongoing maintenance releases, please see the Python 2.7
series.
As noted earlier, Python 2.6, Python 2.7, and Python 3.X all have
support for the PEP 3118 buffer protocol. Python releases prior
to 2.6 use an older buffer protocol. Since Python 2.6 has been
retired for a good while now, it seems reasonable to me to remove
code using the older buffer protocol from GDB.
I have also simplified some of the code via use of the Py_buffer
unique_ptr specialization which I introduced in the two argument
gdb.Value constructor patch series. Therefore, there is a dependency
on patch #1 from that series.
I have tested against both Python 2.7.15 and 3.7.2. I see no
regressions among the non-racy tests. I've also verified that
PyBuffer_Release is being called when the affected functions exit
while running the tests in gdb.python/py-inferior.exp by hand. I've
also tried running valgrind on GDB while running this test, but I'm
puzzled by the results that I'm seeing - I'm seeing no additional
leaks when I comment out the Py_buffer_up lines that I introduced.
That said, I'm not seeing any leaks that obviously originate from
either infpy_write_memory() or infpy_search_memory().
gdb/ChangeLog:
* python/py-inferior.c (infpy_write_memory): Remove non-IS_PY3K
code from these functions. Remove corresponding ifdefs. Use
Py_buffer_up instead of explicit calls to PyBuffer_Release.
Remove gotos and target of gotos.
(infpy_search_memory): Likewise.
Make use of the default gdbarch method for gdbarch_dummy_id.
I have not tested this change but, by inspecting the code, I believe
the default method is equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/hppa-tdep.c (hppa_dummy_id): Delete.
(hppa_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/h8300-tdep.c (h8300_unwind_pc): Delete.
(h8300_unwind_sp): Delete.
(h8300_dummy_id): Delete.
(h8300_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/ft32-tdep.c (ft32_dummy_id): Delete.
(ft32_unwind_pc): Delete.
(ft32_unwind_sp): Delete.
(ft32_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/frv-tdep.c (frv_dummy_id): Delete.
(frv_unwind_pc): Delete.
(frv_unwind_sp): Delete.
(frv_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
This change has been tested with no regressions.
gdb/ChangeLog:
* gdb/riscv-tdep.c (riscv_dummy_id): Delete.
(riscv_unwind_pc): Delete.
(riscv_unwind_sp): Delete.
(riscv_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/csky-tdep.c (csky_dummy_id): Delete.
(csky_unwind_pc): Delete.
(csky_unwind_sp): Delete.
(csky_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/cris-tdep.c (cris_dummy_id): Delete.
(cris_unwind_pc): Delete.
(cris_unwind_sp): Delete.
(cris_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
and gdbarch_unwind_pc.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/bfin-tdep.c (bfin_dummy_id): Delete.
(bfin_unwind_pc): Delete.
(bfin_gdbarch_init): Don't register deleted functions with gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/arm-tdep.c (arm_dummy_id): Delete.
(arm_unwind_pc): Delete.
(arm_unwind_sp): Delete.
(arm_gdbarch_init): Don't register deleted functions with gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted. The
only difference is that the old ARC specific methods had additional
debugging, however, this was discussed on the mailing list[1] and it
was agreed these methods could be removed.
[1] https://sourceware.org/ml/gdb-patches/2018-12/msg00386.html
gdb/ChangeLog:
* gdb/arc-tdep.c (arc_dummy_id): Delete.
(arc_unwind_pc): Delete.
(arc_unwind_sp): Delete.
(arc_gdbarch_init): Don't register deleted functions with gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id, and
gdbarch_unwind_pc.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/alpha-tdep.c (alpha_dummy_id): Delete.
(alpha_unwind_pc): Delete.
(alpha_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/aarch64-tdep.c (aarch64_dummy_id): Delete.
(aarch64_unwind_pc): Delete.
(aarch64_unwind_sp): Delete.
(aarch64_gdbarch_init): Don't register deleted functions with
gdbarch.
Committed on behalf of Matthew Malcomson.
This allows checking the command line parsing more easily than before by
allowing many command line invokations from the same .d file.
Each line is used as a set of flags, and the tests are ran against the output
of the assembler with each set.
Each line of assembler is treated as another set of tests (as if the test file
were copied to another with a different #as: line).
This patch includes some example uses where multiple testcases can be merged
into one file using this new functionality.
binutils/ChangeLog:
* testsuite/lib/binutils-common.exp: Allow multiple "as" lines.
gas/ChangeLog:
* testsuite/gas/aarch64/dotproduct.d: Use multiple "as" lines.
* testsuite/gas/aarch64/dotproduct_armv8_4.d: Remove.
* testsuite/gas/aarch64/dotproduct_armv8_4.s: Remove.
* testsuite/gas/aarch64/illegal-dotproduct.d: Use multiple "as"
lines.
* testsuite/gas/aarch64/ldst-rcpc-armv8_2.d: Remove.
* testsuite/gas/aarch64/ldst-rcpc.d: Use multiple "as" lines.
In 'type_align' when computing the alignment of a structure we should
not consider the alignment of static structure members, these are
usually stored outside of the structure and therefore don't have any
impact on the structures alignment requirements.
I've extended the existing alignment calculating test to compile in
both C and C++ now so that we can create structures with static
members.
gdb/ChangeLog:
* gdbtypes.c (type_align): Don't consider static members when
computing structure alignment.
gdb/testsuite/ChangeLog:
* gdb.base/align.exp: Extend to compile in both C and C++, and add
tests for structs with static members.
This commit restructures the relationship between the type_align
function and the gdbarch_type_align method.
The problem being addressed with this commit is this; previously the
type_align function was structured so that for "basic" types (int,
float, etc) the gdbarch_type_align hook was called, which for
"compound" types (arrays, structs, etc) the common type_align code has
a fixed method for how to extract a "basic" type and would then call
itself on that "basic" type.
The problem is that if an architecture wants to modify the alignment
rules for a "compound" type then this is not currently possible.
In the revised structure, all types pass through the
gdbarch_type_align method. If this method returns 0 then this
indicates that the architecture has no special rules for this type,
and GDB should apply the default rules for alignment. However, the
architecture is free to provide an alignment for any type, both
"basic" and "compound".
After this commit the default alignment rules now all live in the
type_align function, the default_type_align only ever returns 0,
meaning apply the default rules.
I've updated the 3 targets (arc, i386, and nios2) that already
override the gdbarch_type_align method to fit the new scheme.
Tested on X86-64/GNU Linux with no regressions.
gdb/ChangeLog:
* arc-tdep.c (arc_type_align): Provide alignment for basic types,
return 0 for other types.
* arch-utils.c (default_type_align): Always return 0.
* gdbarch.h: Regenerate.
* gdbarch.sh (type_align): Extend comment.
* gdbtypes.c (type_align): Add additional comments, always call
gdbarch_type_align before applying the default rules.
* i386-tdep.c (i386_type_align): Return 0 as the default rule,
generic code will then apply a suitable default.
* nios2-tdep.c (nios2_type_align): Provide alignment for basic
types, return 0 for other types.
Now that the GDB 8.3 branch has been created, we can
bump the version number.
gdb/ChangeLog:
GDB 8.3 branch created (143420fb0d):
* version.in: Bump version to 8.3.50.DATE-git.
When the target description support was added to RISC-V, the register
numbers assigned to the fflags, frm, and fcsr control registers in the
default target descriptions didn't match the register numbers used by
GDB before the target description support was added.
What this means is that if a tools exists in the wild that is using
hard-coded register number, setup to match GDB's old numbering, then
this will have been broken (for fflags, frm, and fcsr) by the move to
target descriptions. QEMU is such a tool.
There are a couple of solutions that could be used to work around this
issue:
- The user can create their own xml description file with the
register numbers setup to match their old tool, then load this by
telling GDB 'set tdesc filename FILENAME'.
- Update their old tool to use the newer default numbering scheme, or
better yet add proper target description support to their tool.
- We could have RISC-V GDB change to maintain the old defaults.
This patch changes GDB back to using the old numbering scheme.
This change is only visible to remote targets that don't supply their
own xml description file and instead rely on GDB's default numbering.
Note that even though 32bit-cpu.xml and 64bit-cpu.xml have changed,
the corresponding .c file has not, this is because the numbering added
to the registers in the xml files is number 0, this doesn't result in
any new C code being generated .
gdb/ChangeLog:
* features/riscv/32bit-cpu.xml: Add register numbers.
* features/riscv/32bit-fpu.c: Regenerate.
* features/riscv/32bit-fpu.xml: Add register numbers.
* features/riscv/64bit-cpu.xml: Add register numbers.
* features/riscv/64bit-fpu.c: Regenerate.
* features/riscv/64bit-fpu.xml: Add register numbers.
The new test case in py-value.exp fails -- the code was changed to
throw ValueError, but the test still checks for TypeError. This patch
fixes the problem.
I'm checking this in. Tested on x86-64 Fedora 29.
gdb/testsuite/ChangeLog
2019-02-26 Tom Tromey <tromey@adacore.com>
* gdb.python/py-value.exp (test_value_from_buffer): Check for
ValueError, not TypeError.
gdb/ChangeLog:
* NEWS: Mention two argument form of gdb.Value constructor.
gdb/doc/ChangeLog:
* python.texi (Values From Inferior): Document second form
of Value.__init__.
Provided a buffer BUFOBJ and a type TYPE, construct a gdb.Value object
with type TYPE, where the value's contents are taken from BUFOBJ.
E.g...
(gdb) python import struct
(gdb) python unsigned_int_type=gdb.lookup_type('unsigned int')
(gdb) python b=struct.pack('=I',0xdeadbeef)
(gdb) python v=gdb.Value(b, unsigned_int_type) ; print("%#x" % v)
0xdeadbeef
This two argument form of the gdb.Value constructor may also be used
to obtain gdb values from selected portions of buffers read with
Inferior.read_memory(). The test case (which is in a separate patch)
demonstrates this use case.
gdb/ChangeLog:
* python/py-value.c (convert_buffer_and_type_to_value): New
function.
(valpy_new): Parse arguments via gdb_PyArg_ParseTupleAndKeywords.
Add support for handling an optional second argument. Call
convert_buffer_and_type_to_value as appropriate.
This patch causes PyBuffer_Release() to be called when the associated
buffer goes out of scope. I've been using it as follows:
...
Py_buffer_up buffer_up;
Py_buffer py_buf;
if (PyObject_CheckBuffer (obj)
&& PyObject_GetBuffer (obj, &py_buf, PyBUF_SIMPLE) == 0)
{
/* Got a buffer, py_buf, out of obj. Cause it to released
when it goes out of scope. */
buffer_up.reset (&py_buf);
}
...
This snippet of code was taken directly from an upcoming patch to
python-value.c.
gdb/ChangeLog:
* python/python-internal.h (Py_buffer_deleter): New struct.
(Py_buffer_up): New typedef.
Previously if build_id_verify failed, dwz_bfd was cleared to NULL via
release(), but the BFD object was not destroyed. Use reset() with
nullptr instead to delete the BFD.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_get_dwz_file): Reset dwz_bfd to nullptr
instead of releasing ownership.
When loading dwp files, we create an array of ELF sections indexed by the ELF
section index in the dwp file. The size of this array is calculated by
section_count, as returned by bfd_count_sections, plus 1 (to account for the
null section at index 0). However, when loading the bfd file, strtab/symtab
sections are not added to the list, nor do they increment section_count, so
section_count is actually smaller than the number of ELF sections.
This happens to work when using GNU dwp, which lays out .debug section first,
with sections like .shstrtab coming at the end. Other tools, like llvm-dwp, put
.strtab first, and gdb crashes when loading those dwp files.
For instance, with the current state of gdb, loading a file like this:
$ readelf -SW <file.dwp>
[ 0] <empty>
[ 1] .debug_foo PROGBITS ...
[ 2] .strtab STRTAB ...
... results in section_count = 2 (.debug is the only thing placed into
bfd->sections, so section_count + 1 == 2), and sectp->this_idx = 1 when mapping
over .debug_foo in dwarf2_locate_common_dwp_sections, which passes the
assertion that 1 < 2.
However, using a dwp file produced by llvm-dwp:
$ readelf -SW <file.dwp>
[ 0] <empty>
[ 1] .strtab STRTAB ...
[ 2] .debug_foo PROGBITS ...
... results in section_count = 2 (.debug is the only thing placed into
bfd->sections, so section_count + 1 == 2), and sectp->this_idx = 2 when mapping
over .debug_foo in dwarf2_locate_common_dwp_sections, which fails the assertion
that 2 < 2.
The assertion hit is:
gdb/dwarf2read.c:13009: internal-error: void dwarf2_locate_common_dwp_sections(bfd*, asection*, void*): Assertion `elf_section_nr < dwp_file->num_sections' failed.
This patch changes the calculation of section_count to use elf_numsections,
which should return the actual number of ELF sections.
commit 192b62ce0b ("Use class to manage
BFD reference counts") changed darwin_get_dyld_bfd to use:
+ dyld_bfd.release ();
rather than
- do_cleanups (cleanup);
However, using release here leaks the BFD. Instead, simply assigning
"sub" to "dyld_bfd" achieves what was meant.
gdb/ChangeLog
2019-02-25 Tom Tromey <tromey@adacore.com>
* solib-darwin.c (darwin_get_dyld_bfd): Don't release dyld_bfd.
* objdump.c (sym_ok): New function.
(find_symbol_for_address): Use new function.
(disassemble_section): Compare sections by name, not pointer.
(dump_dwarf): Move code to initialise byte_get pointer and iterate
over separate debug files from here to ...
(dump_bfd): ... here. Add parameter indicating that a separate
debug info file is being dumped. For main file, pull in the
symbol tables from all separate debug info files.
(display_object): Update call to dump_bfd.
* doc/binutils.texi: Document extened behaviour of the
--dwarf=follow-links option.
* NEWS: Mention this new feature.
* testsuite/binutils-all/objdump.WK2: Update expected output.
* testsuite/binutils-all/objdump.exp (test_follow_debuglink): Add
options and dump file parameters.
Add extra test.
* testsuite/binutils-all/objdump.WK3: New file.
* testsuite/binutils-all/readelf.exp: Change expected output for
readelf -wKis test.
* testsuite/binutils-all/readelf.wKis: New file.
Fixes non-ELF powerpc build failure:
tc-ppc.c:3009:1: error: ‘parse_tls_arg’ defined but not used
* config/tc-ppc.c (parse_tls_arg): Wrap in #ifdef OBJ_ELF.
Back when I proposed the '--readnever' feature, I somehow forgot or
decided not to include the bits related to gcore.in in the original
patch. This patch finally updates the gcore script to invoke GDB
using '--readnever'.
We've been carrying this patch on Fedora GDB for quite some time, and
as expected the corefiles generated by gcore on Fedora don't have
problems, which I think is the best indicator that the it's safe to
generate corefiles using '--readnever'.
gdb/ChangeLog:
2019-02-23 Sergio Durigan Junior <sergiodj@redhat.com>
* gcore.in: Add '--readnever' option when invoking GDB.
This patch fixes the copyright year range which escaped
the 2019 update, because the patch was submitted in 2018, but
only really pushed in 2019.
Pushed: https://www.sourceware.org/ml/gdb-patches/2019-02/msg00109.html
Submitted: https://www.sourceware.org/ml/gdb-patches/2018-12/msg00444.html
We normally are pretty good at remembering those little things,
but this one fell through the cracks. This commit fixes this,
by re-running the copyright.py script and checking in the changes
made by that script.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_ref_changeable.exp: Update copyright year range.
* gdb.ada/mi_ref_changeable/foo_rb20_056.adb: Likewise.
* gdb.ada/mi_ref_changeable/pck.adb: Likewise.
* gdb.ada/mi_ref_changeable/pck.ads: Likewise.
* gdb.dwarf2/inlined_subroutine-inheritance.exp: Likewise.
I missed those files which need to be updated manually when I did
the copyright year range update. The copyright.py script reminds
us of that fact with the following message at the end...
REMINDER: Multiple copyright headers must be updated by hand:
gdb/doc/gdb.texinfo
gdb/doc/refcard.tex
gdb/gdbarch.sh
... and somehow I missed this. This commit makes the change for
gdb.texinfo and refcard.tex. gdbarch.sh is being updated separately
by Andrew Burgess.
gdb/doc/ChangeLog:
* gdb.texinfo: Update copyright year ranges.
* refcard.tex: Likewise.
When looking for a separate debug file that matches a given build-id,
GDB only looks in the host's debug dir (typically /usr/lib/debug). This
patch makes it look in the sysroot as well. This is to match the
behavior of GDB when using debuglink-based separate debug files,
introduced in :
402d2bfec4 ("Look for separate debug files in debug directories under a sysroot.")
In the following example, my sysroot is "/tmp/sysroot" and I am trying
to load symbols for
/tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so. This is
the current behavior:
(gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so
Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so...
Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so
Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path
<snip>
(No debugging symbols found in /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so)
With this patch:
(gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so
Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so...
Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so
Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path
Trying /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... yes!
Reading symbols from /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug...
In the original code, there is a suspicious "abfd.release ()" in
build_id_to_debug_bfd, that I don't understand. If a file with the
right name exists but its build-id note doesn't match, we release (leak)
our reference, meaning the file will stay open? I removed it in the new
code, so that the reference is dropped if we end up not using that file.
I tested briefly by corrupting a separate debug file to trigger this
code, nothing exploded.
gdb/ChangeLog:
* build-id.c (build_id_to_debug_bfd_1): New function.
(build_id_to_debug_bfd): Look for separate debug file in
sysroot.
The copyright year that gdbarch.sh places into the generated files
gdbarch.{c,h} wasn't updated at the start of the year. After this
commit the gdbarch.{c,h} files regenerate as the currently are in the
tree.
gdb/ChangeLog:
* gdbarch.sh: Update the copyright year range that is placed into
generated files.
This patch attempts to fix a bug dealing with setting breakpoints
in default symtabs that are symlinks. For example:
(gdb) list
11 GNU General Public License for more details.
12
13 You should have received a copy of the GNU General Public License
14 along with this program. If not, see <http://www.gnu.org/licenses/>. */
15
16 static int
17 foo (void)
18 {
19 return 0; /* break here */
20 }
(gdb)
21
22 int
23 main (void)
24 {
25 return foo ();
26 }
(gdb) b 19
No line 19 in the current file.
Make breakpoint pending on future shared library load? (y or [n])
The problem here is that when create_sals_line_offset sets the default
symtab, it immediately calls symtab_to_fullname, passing that fullname
to collect_symtabs_from_filename to find all matching symtabs. This
fails because we end up looking for a symtab with the name of the
actual file on disk (which is different in this case because of the
symlink) instead of the one stored in the debug info.
Since we already have the lookup name of the default symtab, use it
instead of the fullname. [This fullname thing was originally added
in 2007 in a series dealing with *displaying* absolute file names.
Clearly, this instance has nothing to do with the display of file names.]
gdb/ChangeLog
PR symtab/23853
* linespec.c (create_sals_line_offset): Search for the default
symtab's filename instead of its fullname.
gdb/testsuite/ChangeLog
PR symtab/23853
* gdb.base/symlink-sourcefile.c: New file.
* gdb.base/symlink-sourcefile.exp: New file.
Tom Tromey
Pedro Alves
Saagar Jha
Kevin Buettner
Andrew Burgess
Matthew Malcomson
Joel Brobecker
Simon Marchi
GDB Administrator
John Baldwin
Jordan Rupprecht
Nick Clifton
Alan Modra
Sergio Durigan Junior
Simon Marchi
Keith Seitz