aboutsummaryrefslogtreecommitdiff
path: root/gdbsupport/errors.cc
AgeCommit message (Collapse)AuthorFilesLines
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi1-1/+0
Now that defs.h, server.h and common-defs.h are included via the `-include` option, it is no longer necessary for source files to include them. Remove all the inclusions of these files I could find. Update the generation scripts where relevant. Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 Approved-By: Pedro Alves <pedro@palves.net>
2024-02-23Fix throw_winerror_with_name build error on x86-64 CygwinPedro Alves1-1/+1
The GDB build currently fails on x86-64 Cygwin, with: src/gdbsupport/errors.cc: In function ‘void throw_winerror_with_name(const char*, ULONGEST)’: src/gdbsupport/errors.cc:152:12: error: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ULONGEST’ {aka ‘long unsigned int’} [-Werror=format=] 152 | error (_("%s (error %d): %s"), string, err, strwinerror (err)); | ^ Fix this by adding a cast. While at it, the error codes are really a DWORD that results from a GetLastError() call, so I think unsigned is more appropriate. That is also what strwinerror already does: sprintf (buf, "unknown win32 error (%u)", (unsigned) error); The cast is necessary on MinGW GDB as well, where ULONGEST is unsigned long long, but for some reason, I don't get a warning there. Approved-By: Tom Tromey <tom@tromey.com> Change-Id: I3f5faa779765fd8021abf58bb5f68d556b309d17
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
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.
2023-11-27Introduce throw_winerror_with_nameTom Tromey1-0/+8
This introduces throw_winerror_with_name, a Windows analog of perror_with_name, and changes various places in gdb to call it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770
2023-02-10Move implementation of perror_with_name to gdbsupportAaron Merey1-0/+24
gdbsupport/errors.h declares perror_with_name and leaves the implementation to the clients. However gdb and gdbserver's implementations are essentially the same, resulting in unnecessary code duplication. Fix this by implementing perror_with_name in gdbsupport. Add an optional parameter for specifying the errno used to generate the error message. Also move the implementation of perror_string to gdbsupport since perror_with_name requires it. Approved-By: Tom Tromey <tom@tromey.com>
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-11-13Fix Cygwin build after 02d04eacJon Turney1-2/+2
Commit 02d04eac "Use strwinerror in gdb/windows-nat.c" also moves strwinerror() under the USE_WIN32API conditional, which is not defined for Cygwin (and looks like it shouldn't be, as appears to imply non-POSIX and MiNGW and WinSock...) Also enable the declaration and definition of strwinerror() when __CYGWIN__ is defined.
2022-10-19internal_error: remove need to pass __FILE__/__LINE__Pedro Alves1-2/+2
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-08-16Use strwinerror in gdb/windows-nat.cTom Tromey1-0/+54
When working on windows-nat.c, it's useful to see an error message in addition to the error number given by GetLastError. This patch moves strwinerror from gdbserver to gdbsupport, and then updates windows-nat.c to use it. A couple of minor changes to strwinerror (constify the return type and use the ARRAY_SIZE macro) are also included.
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/+69
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.
generated by cgit v1.1 at 2024-08-26 23:40:52 +0000