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.
Currently, every internal_error call must be passed __FILE__/__LINE__
explicitly, like:
internal_error (__FILE__, __LINE__, "foo %d", var);
The need to pass in explicit __FILE__/__LINE__ is there probably
because the function predates widespread and portable variadic macros
availability. We can use variadic macros nowadays, and in fact, we
already use them in several places, including the related
gdb_assert_not_reached.
So this patch renames the internal_error function to something else,
and then reimplements internal_error as a variadic macro that expands
__FILE__/__LINE__ itself.
The result is that we now should call internal_error like so:
internal_error ("foo %d", var);
Likewise for internal_warning.
The patch adjusts all calls sites. 99% of the adjustments were done
with a perl/sed script.
The non-mechanical changes are in gdbsupport/errors.h,
gdbsupport/gdb_assert.h, and gdb/gdbarch.py.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
When building gdb with -fsanitize=undefined, I run into:
...
(gdb) PASS: gdb.ada/access_to_packed_array.exp: set logging enabled on
maint print symbols^M
print-utils.cc:281:29:runtime error: negation of -9223372036854775808 cannot \
be represented in type 'long int'; cast to an unsigned type to negate this \
value to itself
(gdb) FAIL: gdb.ada/access_to_packed_array.exp: maint print symbols
...
By running in a debug session, we find that this happens during printing of:
...
typedef system.storage_elements.storage_offset: \
range -9223372036854775808 .. 9223372036854775807;
...
Possibly, an ada test-case could be created that exercises this in isolation.
The problem is here in int_string, where we negate a val with type LONGEST:
...
return decimal2str ("-", -val, width);
...
Fix this by, as recommend, using "-(ULONGEST)val" instead.
Tested on x86_64-linux.
Currently, neither phex nor phex_nz handle sizeof_l==1 -- they let
this case fall through to the default case. However, a subsequent
patch in this series needs this case to work correctly.
I looked at all calls to these functions that pass a 1 for the
sizeof_l parameter. The only such case seems to be correct with this
change.
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.
This patch renames the .c source files in gdbsupport to .cc.
In the gdb directory, there is an argument against renaming the source
files, which is that it makes using some git commands more difficult to
do archeology. Some commands have some kind of "follow" option that
makes git try to follow renames, but it doesn't work in all situations.
Given that we have just moved the gdbsupport directory, that argument
doesn't hold for source files in that directory. I therefore suggest
renaming them to .cc, so that they are automatically recognized as C++
by various tools and editors.
The original motivation behind this is that when building gdbsupport
with clang, I get:
CC agent.o
clang: error: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Werror,-Wdeprecated]
In the gdb/ directory, we make clang happy by passing "-x c++". We
could do this in gdbsupport too, but I think that renaming the files is
a better long-term solution.
gdbserver still does its own build of gdbsupport, so a few changes in
its Makefile are necessary.
gdbsupport/ChangeLog:
* Makefile.am: Rename source files from .c to .cc.
(CC, CFLAGS): Don't override.
(AM_CFLAGS): Rename to ...
(AM_CXXFLAGS): ... this.
* Makefile.in: Re-generate.
* %.c: Rename to %.cc.
gdbserver/ChangeLog:
* Makefile.in: Rename gdbsupport source files from .c to .cc.
