aboutsummaryrefslogtreecommitdiff
path: root/gdbsupport/print-utils.cc
AgeCommit message (Collapse)AuthorFilesLines
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
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.
2022-10-19internal_error: remove need to pass __FILE__/__LINE__Pedro Alves1-7/+4
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
2022-05-23[gdbsupport] Fix UB in print-utils.cc:int_stringTom de Vries1-1/+5
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.
2022-03-07Let phex and phex_nz handle sizeof_l==1Tom Tromey1-0/+8
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.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
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.
2021-01-01Update copyright year range in all GDB filesJoel Brobecker1-1/+1
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.
2020-02-13gdbsupport: rename source files to .ccSimon Marchi1-0/+326
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.