| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
|
|
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
|
|
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
|
|
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
|
|
I've been playing with a board file that forces every testcase to
include a header file that does something like:
#define main __gdb_testcase_main
and then links an actual main() function that does some
initialization and then jumps to __gdb_testcase_main.
That runs into a number of testcases relying on main not having an
explicit return statement, like e.g.,:
gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/catch-follow-exec.c:27:1: warning: non-void function does not return a value [-Wreturn-type]
gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/catch-signal.c:47:1: warning: non-void function does not return a value [-Wreturn-type]
We don't get those warnings without my board because it is valid to
not explicitly return from main. There's an implicit "return 0;".
Since it doesn't hurt to be explicit, I've went ahead and added the
explicit return statements.
Also, a couple testcases either don't explicitly specify main's return
type, or return void. Those are tweaked to explicitly return int.
gdb/testsuite/ChangeLog:
* gdb.base/catch-follow-exec.c (main): Add explicit return
statement.
* gdb.base/catch-signal.c (main): Likewise.
* gdb.base/condbreak-call-false.c (main): Likewise.
* gdb.base/consecutive.c (main): Add explicit return
statement and return type.
* gdb.base/cursal.c (main): Add explicit return statement.
* gdb.base/cvexpr.c (main): Likewise.
* gdb.base/display.c (main): Add explicit return statement and
return type.
* gdb.base/dprintf-detach.c (main): Add explicit return statement.
* gdb.base/endianity.c (main): Likewise.
* gdb.base/execd-prog.c (main): Likewise.
* gdb.base/gdb1090.c (main): Likewise.
* gdb.base/info_qt.c (main): Likewise.
* gdb.base/lineinc.c (main): Likewise.
* gdb.base/load-command.c (main): Likewise.
* gdb.base/macscp1.c (main): Likewise.
* gdb.base/pr10179-a.c (main): Likewise.
* gdb.base/quit-live.c (main): Likewise.
* gdb.base/scope0.c (main): Likewise.
* gdb.base/settings.c (main): Likewise.
* gdb.base/stack-checking.c (main): Return int.
* gdb.base/varargs.c (main): Add explicit return statement.
* gdb.cp/ambiguous.cc (main): Likewise.
* gdb.cp/anon-struct.cc (main): Likewise.
* gdb.cp/anon-union.cc (main): Likewise.
* gdb.cp/bool.cc (main): Likewise.
* gdb.cp/bs15503.cc (main): Likewise.
* gdb.cp/cplusfuncs.cc (main): Likewise.
* gdb.cp/cttiadd.cc (main): Likewise.
* gdb.cp/extern-c.cc (main): Likewise.
* gdb.cp/filename.cc (main): Likewise.
* gdb.cp/formatted-ref.cc (main): Likewise.
* gdb.cp/mb-ctor.cc (main): Likewise.
* gdb.cp/member-ptr.cc (main): Likewise.
* gdb.cp/minsym-fallback-main.cc (main): Likewise.
* gdb.cp/overload-const.cc (main): Likewise.
* gdb.cp/paren-type.cc (main): Likewise.
* gdb.cp/parse-lang.cc (main): Likewise.
* gdb.cp/pr-1023.cc (main): Likewise.
* gdb.cp/psmang1.cc (main): Likewise.
* gdb.cp/readnow-language.cc (main): Likewise.
* gdb.cp/ref-params.cc (main): Likewise.
* gdb.cp/rvalue-ref-params.cc (main): Likewise.
* gdb.cp/virtbase2.cc (main): Likewise.
* gdb.dwarf2/dw2-abs-hi-pc.c (main): Likewise.
* gdb.dwarf2/dw2-namespaceless-anonymous.c (main): Likewise.
* gdb.dwarf2/dw4-toplevel-types.cc (main): Likewise.
* gdb.mi/mi-console.c (main): Likewise.
* gdb.mi/mi-read-memory.c (main): Likewise.
* gdb.modula2/multidim.c (main): Likewise.
* gdb.opt/inline-small-func.c (main): Likewise.
* gdb.python/py-rbreak.c (main): Likewise.
* gdb.stabs/exclfwd1.c (main): Likewise.
* gdb.trace/qtro.c (main): Likewise.
|
|
In this commit:
commit 8c95582da858ac981f689a6f599acacb8c5c490f
Date: Mon Dec 30 21:04:51 2019 +0000
gdb: Add support for tracking the DWARF line table is-stmt field
A change was made in buildsym_compunit::record_line to remove
duplicate line table entries in some cases. This was an invalid
change, as these duplicate line table entries are used in _some_ cases
as part of prologue detection (see skip_prologue_using_sal).
It might be possible to identify those line table entries that are
required by skip_prologue_using_sal and only keep those duplicates
around, however, I have not done this here. The original duplicate
removal was done because (a) it was easy to implement, and (b) it
seemed obviously harmless.
As (b) is now known to be false, and implementation would be more
complex, and so (a) is also false. As such, it seems better to keep
all duplicates until an actual reason presents itself for why we
should remove any.
The original regression was spotted on RISC-V, which makes use of
skip_prologue_using_sal as part of riscv_skip_prologue. Originally I
created the test gdb.dwarf2/dw2-inline-small-func.exp, however, this
test will not compile on RISC-V as this target doesn't support
.uleb128 or .sleb128 assembler directives containing complex
expressions. As a result I added the gdb.opt/inline-small-func.exp
test, which exposes the bug on RISC-V, but obviously depends on the
compiler to produce specific DWARF information in order to expose the
bug. Still this test does ensure we always get the desired result,
even if the DWARF changes.
Originally the gdb.dwarf2/dw2-inline-small-func.exp test passed on
x86-64 even with the duplicate line table entries incorrectly
removed. The reason for this is that when a compilation unit doesn't
have a 'producer' string then skip_prologue_using_sal is not used,
instead the prologue is always skipped using analysis of the assembler
code.
However, for Clang on x86-64 skip_prologue_using_sal is used, so I
modified the gdb.dwarf2/dw2-inline-small-func.exp test to include a
'producer' string that names the Clang compiler. With this done the
test would fail on x86-64.
One thing to note is that the gdb.opt/inline-small-func.exp test might
fail on some targets. For example, if we compare sparc to risc-v by
looking at sparc32_skip_prologue we see that this function doesn't use
skip_prologue_using_sal, but instead uses find_pc_partial_function
directly. I don't know the full history behind why the code is like
it is, but it feels like sparc32_skip_prologue is an attempt to
duplicate some of the functionality of skip_prologue_using_sal, but
without all of the special cases. If this is true then the new test
could easily fail on this target, this would suggest that sparc should
consider switching to use skip_prologue_using_sal like risc-v does.
gdb/ChangeLog:
* buildsym.c (buildsym_compunit::record_line): Remove
deduplication code.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-inline-small-func-lbls.c: New file.
* gdb.dwarf2/dw2-inline-small-func.c: New file.
* gdb.dwarf2/dw2-inline-small-func.exp: New file.
* gdb.dwarf2/dw2-inline-small-func.h: New file.
* gdb.opt/inline-small-func.c: New file.
* gdb.opt/inline-small-func.exp: New file.
* gdb.opt/inline-small-func.h: New file.
|
