aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-09-11sim: run: change help short option to -hMike Frysinger1-1/+1
It's unclear why -H was picked over the more standard -h, but since -h is still not used, just change -H to -h to match pretty much every other tool in the sourceware tree.
2021-09-11Automatic date update in version.inGDB Administrator1-1/+1
2021-09-10[gdb/testsuite] Reimplement gdb.gdb/python-selftest.exp as unittestTom de Vries2-30/+46
The test-case gdb.gdb/python-selftest.exp: - patches the gdb_python_initialized variable in gdb to 0 - checks that the output of a python command is "Python not initialized" Reimplement gdb.gdb/python-selftest.exp as unittest, using: - execute_command_to_string to capture the output - try/catch to catch the "Python not initialized" exception. Tested on x86_64-linux.
2021-09-10[gdb/testsuite] Fix DUPLICATE in gdb.base/global-var-nested-by-dso.expTom de Vries1-2/+2
Fix DUPLICATE in gdb.base/global-var-nested-by-dso.exp by naming commands more uniquely.
2021-09-10[gdb/testsuite] Fix DUPLICATE in gdb.base/skip-solib.expTom de Vries1-55/+49
Fix DUPLICATE in gdb.base/skip-solib.exp by using with_test_prefix. Also fix indentation style and long lines, remove outdated question/answer bits, and use multi_line.
2021-09-10[gdb/testsuite] Fix handling of nr_args < 3 in mi_gdb_testTom de Vries6-12/+43
The documentation of mi_gdb_test states that the command, pattern and message arguments are mandatory: ... # mi_gdb_test COMMAND PATTERN MESSAGE [IPATTERN] -- send a command to gdb; # test the result. ... However, this is not checked, and when mi_gdb_test is called with less than 3 arguments, it passes or fails silently. Fix this by using the following semantics: - if there are 1 or 2 arguments, use the command as the message. - if there is 1 argument, use ".*" as the pattern. - if there are no or too much arguments, error out. Fix a PATH issue in gdb.mi/mi-logging.exp, introduced by using the command as message. Fix a few other trivial-looking FAILs. There are 11 less trivial-looking FAILs left in gdb.mi in test-cases: - mi-nsmoribund.exp - mi-breakpoint-changed.exp - mi-break.exp. Tested on x86_64-linux.
2021-09-10[gdb/testsuite] Add string_list_to_regexpTom de Vries2-0/+78
A regexp pattern with escapes like this is hard to read: ... set re "~\"\[$\]$decimal = 1\\\\n\"\r\n\\^done" ... We can make it more readable by spacing out parts (which allows us to also use the curly braces where that's convenient): ... set re [list "~" {"} {[$]} $decimal " = 1" "\\\\" "n" {"} "\r\n" "\\^" "done"] set re [join $re ""] ... or by using string_to_regexp: ... set re [list \ [string_to_regexp {~"$}] \ $decimal \ [string_to_regexp " = 1\\n\"\r\n^done"]] set re [join $re ""] ... Note: we have to avoid applying string_to_list to decimal, which is already a regexp. Add a proc string_list_to_regexp to make it easy to do both: ... set re [list \ [string_list_to_regexp ~ {"} $] \ $decimal \ [string_list_to_regexp " = 1" \\ n {"} \r\n ^ done]] ... Also add a test-case gdb.testsuite/string_to_regexp.exp.
2021-09-10[gdb/testsuite] Handle unrecognized command line option in gdb_compile_testTom de Vries1-11/+24
When running the gdb testsuite with gnatmake-4.8, I get many fails of the following form: ... gcc: error: unrecognized command line option '-fgnat-encodings=all'^M gnatmake: "gdb.ada/O2_float_param/foo.adb" compilation error^M compiler exited with status 1 compilation failed: gcc ... gdb.ada/O2_float_param/foo.adb gcc: error: unrecognized command line option '-fgnat-encodings=all' gnatmake: "gdb.ada/O2_float_param/foo.adb" compilation error FAIL: gdb.ada/O2_float_param.exp: scenario=all: compilation foo.adb ... Fix this by marking the test unsupported instead, such that we have: ... UNSUPPORTED: gdb.ada/O2_float_param.exp: scenario=all: compilation foo.adb \ (unsupported option '-fgnat-encodings=all') ... Tested on x86_64-linux.
2021-09-10PowerPC, sanity check r_offset in relocate_sectionAlan Modra1-357/+442
* elf32-ppc.c (offset_in_range): New function. (ppc_elf_vle_split16): Sanity check r_offset before accessing section contents. Return status. (ppc_elf_relocate_section): Sanity check r_offset before accessing section contents. Don't segfault on NULL howto.
2021-09-10Re: gas: Use the directory name in .file 0Alan Modra1-18/+18
PR gas/28266 * testsuite/gas/elf/dwarf-5-file0-2.s: Use %object rather than @object, .4byte instead of .long, and .asciz instead of .string.
2021-09-09etc: switch to automakeMike Frysinger5-105/+1787
There's no content in here currently, so switching to automake is pretty easy with a stub file.
2021-09-09etc: rename configure.in to configure.acMike Frysinger1-0/+0
The .in name has been deprecated for a long time in favor of .ac.
2021-09-09gas: Use the directory name in .file 0H.J. Lu4-4/+135
DWARF5 allows .file 0 to take an optional directory name. Set the entry 0 of the directory table to the directory name in .file 0. PR gas/28266 * dwarf2dbg.c (get_directory_table_entry): Add an argument for the directory name in .file 0 and use it, instead of PWD. (allocate_filenum): Pass NULL to get_directory_table_entry. (allocate_filename_to_slot): Pass the incoming dirname to get_directory_table_entry. * testsuite/gas/elf/dwarf-5-file0-2.d: New file. * testsuite/gas/elf/dwarf-5-file0-2.s: Likewise. * testsuite/gas/elf/elf.exp: Run dwarf-5-file0-2.
2021-09-10Automatic date update in version.inGDB Administrator1-1/+1
2021-09-09gdb: Enable target rx-*-*linux.Yoshinori Sato1-1/+1
I added rx-*-linux in binutils few yaers ago. But missing this changes,
2021-09-09[gdb/testsuite] Fix gdb.base/coredump-filter-build-id.exp with older eu-unstripTom de Vries1-1/+2
On openSUSE Leap 42.3 with eu-unstrip 0.158, we run into: ... (gdb) PASS: gdb.base/coredump-filter-build-id.exp: save corefile First line of eu-unstrip: \ 0x400000+0x202000 f4ae8502bd6a14770182382316bc595e9dc6f08b@0x400284 - - [exe] FAIL: gdb.base/coredump-filter-build-id.exp: gcore dumped mapping with build-id ... The test expects an actual file name instead of '[exe]', but that only got introduced with eu-unstrip 0.161. Before it printed '[exe]' or '[pie]'. Fix this by updating the regexp. Tested on x86_64-linux.
2021-09-09[gdb/testsuite] Fix various issues in gdb.mi/mi-sym-info.expTom de Vries1-13/+34
I noticed this failure in gdb.mi/mi-sym-info.exp with gcc-4.8: ... FAIL: gdb.mi/mi-sym-info.exp: -symbol-info-functions --max-results 1 \ (unexpected output) ... due to function f2 instead of f3 being listed. AFAICT, this is caused by a difference in debug info: ... $ readelf -wi outputs/gdb.mi/mi-sym-info/mi-sym-info1.o \ | egrep "DW_AT_name.*: f[1-3]" <72> DW_AT_name : f1 <a1> DW_AT_name : f2 <d0> DW_AT_name : f3 ... vs: ... $ readelf -wi outputs/gdb.mi/mi-sym-info/mi-sym-info1.o \ | egrep "DW_AT_name.*: f[1-3]" <f4> DW_AT_name : f3 <123> DW_AT_name : f2 <152> DW_AT_name : f1 ... and the command documentation does not mention an imposed order, so fix this by allowing f2 as well. Doing this fix, it made sense to do a refactoring of adding f2_re and f3_re variables, in order to write (?:$f2_re|$f3_re), and I applied the same pattern overall. Furthermore, I found a silent FAIL due to calling mi_gdb_proc with 2 args, fix by updating the regexp. Then I ran with clang and found another FAIL, fix by updating the regexp. Tested on x86_64-linux with gcc-4.8.5, gcc-7.5.0, gcc-11.2.1, clang-7.0.1 and clang-12.0.1.
2021-09-09[gdb/testsuite] Reimplement gdb.gdb/complaints.exp as unittestTom de Vries4-152/+94
When building gdb with "-Wall -O2 -g -flto=auto", I run into: ... (gdb) call clear_complaints()^M No symbol "clear_complaints" in current context.^M (gdb) FAIL: gdb.gdb/complaints.exp: clear complaints ... The problem is that lto has optimized away the clear_complaints function and consequently the selftest doesn't work. Fix this by reimplementing the selftest as a unit test. Factor out two new functions: - void execute_fn_to_ui_file (struct ui_file *file, std::function<void(void)> fn); - std::string execute_fn_to_string (std::function<void(void)> fn, bool term_out); and use the latter to capture the complaints output. Tested on x86_64-linux.
2021-09-09gdb/python: remove all uses of Py_TPFLAGS_HAVE_ITERAndrew Burgess7-11/+10
Python 2 has a bit flag Py_TPFLAGS_HAVE_ITER which can be passed as part of the tp_flags field when defining a new object type. This flag is not defined in Python 3 and so we define it to 0 in python-internal.h (when IS_PY3K is defined). The meaning of this flag is that the object has the fields tp_iter and tp_iternext. Note the use of "has" here, the flag says nothing about the values in those fields, just that the type object has the fields. In early versions of Python 2 these fields were no part of the PyTypeObject struct, they were added in version 2.2 (see https://docs.python.org/release/2.3/api/type-structs.html). And so, there could be a some code compiled out there which has a PyTypeObject structure within it that doesn't even have the tp_iter and tp_iternext fields, attempting to access these fields would be undefined behaviour. And so Python added the Py_TPFLAGS_HAVE_ITER flag. If the flag is present then Python is free to access the tp_iter and tp_iternext fields. If we consider GDB then we always assume that the tp_iter and tp_iternext fields are part of PyTypeObject. If someone was crazy enough to try and compile GDB against Python 2.1 then we'd get lots of build errors saying that we were passing too many fields when initializing PyTypeObject structures. And so, I claim, we can be sure that GDB will always be compiled with a version of Python that has the tp_iter and tp_iternext fields in PyTypeObject. Next we can look at the Py_TPFLAGS_DEFAULT flag. In Python 2, each time additional fields are added to PyTypeObject a new Py_TPFLAGS_* flag would be defined to indicate whether those flags are present or not. And, those new flags would be added to Py_TPFLAGS_DEFAULT. And so, in the latest version of Python 2 the Py_TPFLAGS_DEFAULT flag includes Py_TPFLAGS_HAVE_ITER (see https://docs.python.org/2.7/c-api/typeobj.html). In GDB we pass Py_TPFLAGS_DEFAULT as part of the tp_flags for all objects we define. And so, in this commit, I propose to remove all uses of Py_TPFLAGS_HAVE_ITER from GDB, it's simply not needed. There should be no user visible changes after this commit.
2021-09-09sim: accept -EB/-EL short optionsMike Frysinger1-3/+3
Many GNU tools accept -EB/-EL as short options for selecting big & little endian modes. While the sim has an -E option, it requires spelling out "big" and "little". Adding support for -EB & -EL is thus quite trivial, so lets round it out to be less annoying.
2021-09-09sim: ppc: drop support for std-config.h overridesMike Frysinger5-66/+6
Only the ppc arch supports this kind of source file override logic. All the others expose knobs via configure flags, and for some of these, the ppc code does as well. For others, it doesn't make sense to ever change them. Since it's unlikely anyone is using this, drop it all to simplify the code (and to get us a little closer to the common sim code).
2021-09-09sim: ppc: enable use of gnulibMike Frysinger5-2/+26
All other sim arches are using this now, so finish up the logic in the ppc arch to enable gnulib usage here too.
2021-09-09sim: drop old O_NDELAY & FNBLOCK supportMike Frysinger3-25/+7
We use these older names inconsistently in the sim codebase, and time has moved on long ago, so drop support for these non-standard names. POSIX provides O_NONBLOCK for us, so use it everywhere.
2021-09-09sim: dv-sockser: enable for mingw targets tooMike Frysinger3-24/+11
We have enough functionality from gnulib now to build sockser on all platforms. Non-blocking I/O is supported when F_GETFL/F_SETFL are unavailable, but we can address that in a follow up commit. This mirrors what is done in other places in the sim already.
2021-09-09sim: cgen: workaround Windows VOID defineMike Frysinger1-0/+2
The cgen framework provides a "VOID" type for code to use, but this defines ends up conflicting with the standard Windows VOID define. Since they actually define to the same thing ("void"), undef it here to fix the Windows build. We might want to reconsider the need for "VOID" in cgen, but that will take larger discussion & coordination with the cgen project.
2021-09-09sim: dv-sockser: move sim-main.h include after system includesMike Frysinger1-2/+1
The sim-main.h header is a bit of a dumping ground. Every arch can (and many do) define all sorts of weird & common names that end up conflicting with system headers. So including it before the system headers sets us up for pain. v850 is a good example of this -- when building for mingw, we see weird failures: $ i686-w64-mingw32-gcc ... -c -o dv-sockser.o ../../../../sim/v850/../common/dv-sockser.c In file included from ../../../../sim/v850/sim-main.h:11, from ../../../../sim/v850/../common/dv-sockser.c:24: ../../../../sim/v850/../common/sim-base.h:97:32: error: expected ')' before '->' token 97 | # define STATE_CPU(sd, n) ((sd)->cpu[0]) | ^~ While gcc is unhelpful at first, running it through the preprocessor by hand shows more details: $ i686-w64-mingw32-gcc ... -E -dD -o dv-sockser.i ../../../../sim/v850/../common/dv-sockser.c $ i686-w64-mingw32-gcc -c dv-sockser.i In file included from /usr/i686-w64-mingw32/usr/include/minwindef.h:163, from /usr/i686-w64-mingw32/usr/include/windef.h:9, from /usr/i686-w64-mingw32/usr/include/windows.h:69, from /usr/i686-w64-mingw32/usr/include/winsock2.h:23, from ../../gnulib/import/sys/socket.h:684, from ../../gnulib/import/netinet/in.h:43, from ../../../../sim/v850/../common/dv-sockser.c:39: /usr/i686-w64-mingw32/usr/include/winnt.h:4803:25: error: expected ')' before '->' token 4803 | DWORD State; | ^ | ) This is because v850 sets up this common name: All of this needs cleaning up someday, but since the dv-sockser code definitely should be fixed in this way, lets do that now and unblock the v850 code.
2021-09-09sim: mips: delete unused PSIZE defineMike Frysinger1-2/+0
It's unclear what this define is for as it appears to be unused, and has never been used in the history of the mips sim. Delete it to tidy up, and to fix build errors for Windows targets that have a standard "PSIZE" struct in their system headers. This doesn't show up yet as most sim files don't include many system headers, but enabling sockser code for mingw uncovers the conflict. Unfortunately the error produced by gcc is inscrutable, but running it through the preprocessor manually manages to provide a pointer to the underlying issue. $ i686-w64-mingw32-gcc ... -c -o dv-sockser.o ../../../../sim/mips/../common/dv-sockser.c <command-line>: error: expected identifier or '(' before numeric constant In file included from /usr/i686-w64-mingw32/usr/include/windows.h:71, from /usr/i686-w64-mingw32/usr/include/winsock2.h:23, from ../../gnulib/import/sys/socket.h:684, from ../../gnulib/import/netinet/in.h:43, from ../../../../sim/mips/../common/dv-sockser.c:39: /usr/i686-w64-mingw32/usr/include/wingdi.h:2934:59: error: unknown type name 'LPSIZE'; did you mean 'LPSIZEL'? 2934 | WINGDIAPI WINBOOL WINAPI GetAspectRatioFilterEx(HDC hdc,LPSIZE lpsize); | ^~~~~~ | LPSIZEL ... $ i686-w64-mingw32-gcc ... -E -dD -o dv-sockser.i ../../../../sim/mips/../common/dv-sockser.c $ i686-w64-mingw32-gcc -c dv-sockser.i In file included from /usr/i686-w64-mingw32/usr/include/windows.h:69, from /usr/i686-w64-mingw32/usr/include/winsock2.h:23, from ../../gnulib/import/sys/socket.h:684, from ../../gnulib/import/netinet/in.h:43, from ../../../../sim/mips/../common/dv-sockser.c:39: /usr/i686-w64-mingw32/usr/include/windef.h:104:9: error: expected identifier or '(' before numeric constant 104 | } SIZE,*PSIZE,*LPSIZE; | ^~
2021-09-08sim: ppc: switch to common warning flagsMike Frysinger3-109/+2
Now that the ppc code has been cleaned up enough to use the same set of warning flags as the common code, delete the ppc-specific configure logic so we can leverage what the common code already defined for us.
2021-09-08sim: ppc: enable -Wpointer-sign warningsTom de Vries4-6/+8
When compiling with --enable-werror and CFLAGS="-O0 -g -Wall", we run into: ... src/sim/ppc/hw_memory.c: In function 'hw_memory_init_address': src/sim/ppc/hw_memory.c:204:7: error: pointer targets in passing argument 4 \ of 'device_find_integer_array_property' differ in signedness \ [-Werror=pointer-sign] &new_chunk->size); ^ ... Fix these by adding an explicit pointer cast. It's a bit ugly to use APIs based on signed integers to read out unsigned values, but in practice, this is par for the course in the ppc code. We already use signed APIs and assign the result to unsigned values a lot: see how device_find_integer_property returns a signed integer (cell), but then assign it to unsigned types. The array APIs are not used that often which is why we don't see many warnings, and we disable warnings when we assign signed integers to unsigned integers in general. The dtc/libfdt project (which is the standard in other projects) processes the fdt blob as a series of bytes without any type information. Typing is left to the caller. They have core APIs that read/write bytes, and a few helper functions to cast/convert those bytes to the right value (e.g. u32). In this ppc sim code, the core APIs use signed integers, and the callers convert to unsigned, usually implicitly. We could add some core APIs to the ppc sim that deal with raw bytes and then add some helpers to convert to the right type, but that seems like a lot of lifting for what boils down to a cast, and is effectively equivalent to all the implicit assignments we use elsewhere. Long term, a lot of the ppc code should either get converted to existing sim common code, or we should stand up proper APIs in the common code first, or use standard libraries to do all the processing (e.g. libfdt). Either way, this device.c code would all get deleted, and callers (like these hw_*.c files) would get converted. Which is also why we go with a cast rather new (but largely unused) APIs.
2021-09-08sim: ppc: enable -Wmissing-declarations & -Wmissing-prototypesMike Frysinger3-4/+11
This aligns with common code which already uses this flag. We have to add another local prototype to fix the failure, and add another local decl for the SIM_DESC type. Unwinding these will require a lot more work & conversions in the process, so going with the decl for now unblocks the warning unification.
2021-09-08sim: microblaze: replace custom basic types with common onesMike Frysinger4-33/+26
The basic "byte" type conflicts with Windows headers, and we already have common types that provide the right sizes. So replace these with the common ones to avoid issues. CC dv-sockser.o In file included from /usr/i686-w64-mingw32/usr/include/wtypes.h:8, from /usr/i686-w64-mingw32/usr/include/winscard.h:10, from /usr/i686-w64-mingw32/usr/include/windows.h:97, from /usr/i686-w64-mingw32/usr/include/winsock2.h:23, from ../../gnulib/import/sys/socket.h:684, from ../../gnulib/import/netinet/in.h:43, from .../build/sim/../../../sim/microblaze/../common/dv-sockser.c:39: /usr/i686-w64-mingw32/usr/include/rpcndr.h:63:25: error: conflicting types for 'byte'; have 'unsigned char' 63 | typedef unsigned char byte; | ^~~~ In file included from .../buildsim/../../../sim/microblaze/sim-main.h:21, from .../buildsim/../../../sim/microblaze/../common/dv-sockser.c:24: .../buildsim/../../../sim/microblaze/microblaze.h:94:25: note: previous declaration of 'byte' with type 'byte' {aka 'char'} 94 | typedef char byte; | ^~~~ make: *** [Makefile:513: dv-sockser.o] Error 1
2021-09-08RISC-V: Pretty print values formed with lui and addiw.Jim Wilson5-22/+35
The disassembler has support to pretty print values created by an lui/addi pair, but there is no support for addiw. There is also no support for c.addi and c.addiw. This patch extends the pretty printing support to handle these 3 instructions in addition to addi. Existing testcases serve as tests for the new feature. opcodes/ * riscv-dis.c (maybe_print_address): New arg wide. Sign extend when wide is true. (print_insn_args): Fix calls to maybe_print_address. Add checks for c.addi, c.addiw, and addiw, and call maybe_print_address for them. gas/ * testsuite/gas/riscv/insn.d: Update for disassembler change. * testsuite/gas/li32.d, testsuite/gas/li64.d: Likwise. * testsuite/gas/lla64.d: Likewise.
2021-09-08sim: ppc: align format string settings with common codeMike Frysinger3-1/+13
This copies logic used in the common sim warning configure code to fix build errors for mingw targets. Turning format warnings on triggers a failure in the debug.c file, so apply a minor fix at the same time.
2021-09-08sim: ppc: drop unnecessary config includesMike Frysinger1-4/+0
This file is compiled for the --host & --build system which leads to including the configure generated config.h in both environments. This obviously doesn't work when the two targets don't look alike at all and can cause build failures here (e.g. a mingw host & a linux build). Since we don't actually need any config settings in this very simple file, drop the includes entirely.
2021-09-09Automatic date update in version.inGDB Administrator1-1/+1
2021-09-08gnulib: import various network functionsMike Frysinger13-1043/+1711
Some sim ports use these to provide networking functionality via the dv-sockser module or via direct emulation for a few ports. Gdb seems to build just fine still too.
2021-09-08Fix unit test build on WindowsTom Tromey1-1/+2
Like Tom de Vries' earlier patch to fix the no-CXX_STD_THREAD case in maint.c, this patch fixes a similar problem in parallel-for-selftests.c. This fixes a build failure on Windows.
2021-09-08PowerPC64, sanity check r_offset in relocate_sectionAlan Modra1-49/+119
This hardens the powerpc64 linker code transformations. * elf64-ppc.c (is_8byte_reloc, offset_in_range): New functions. (ppc64_elf_relocate_section): Sanity check r_offset before accessing section contents for various code transformations.
2021-09-08PowerPC64: Avoid useless work on R_PPC64_TPREL34Alan Modra1-1/+3
_bfd_elf_ppc_at_tprel_transform doesn't handle prefix instructions, and I'm not inclined to implement code editing for them. * elf64-ppc.c (ppc64_elf_relocate_section): Don't attempt tprel transform for R_PPC64_TPREL34.
2021-09-08gdb: make thread_suspend_state::stop_pc optionalAndrew Burgess4-8/+31
Currently the stop_pc field of thread_suspect_state is a CORE_ADDR and when we want to indicate that there is no stop_pc available we set this field back to a special value. There are actually two special values used, in post_create_inferior the stop_pc is set to 0. This is a little unfortunate, there are plenty of embedded targets where 0 is a valid pc value. The more common special value for stop_pc though, is set in thread_info::set_executing, where the value (~(CORE_ADDR) 0) is used. This commit changes things so that the stop_pc is instead a gdb::optional. We can now explicitly reset the field to an uninitialised state, we also have asserts that we don't read the stop_pc when its in an uninitialised state (both in gdbsupport/gdb_optional.h, when compiling with _GLIBCXX_DEBUG defined, and in thread_info::stop_pc). One situation where a thread will not have a stop_pc value is when the thread is stopped as a consequence of GDB being in all stop mode, and some other thread stopped at an interesting event. When GDB brings all the other threads to a stop those other threads will not have a stop_pc set (thus avoiding an unnecessary read of the pc register). Previously, when GDB passed through handle_one (in infrun.c) the threads executing flag was set to false and the stop_pc field was left unchanged, i.e. it would (previous) have been left as ~0. Now, handle_one leaves the stop_pc with no value. This caused a problem when we later try to set these threads running again, in proceed() we compare the current pc with the cached stop_pc. If the thread was stopped via handle_one then the stop_pc would have been left as ~0, and the compare (in proceed) would (likely) fail. Now however, this compare tries to read the stop_pc when it has no value and this would trigger an assert. To resolve this I've added thread_info::stop_pc_p() which returns true if the thread has a cached stop_pc. We should only ever call thread_info::stop_pc() if we know that there is a cached stop_pc, however, this doesn't mean that every call to thread_info::stop_pc() needs to be guarded with a call to thread_info::stop_pc_p(), in most cases we know that the thread we are looking at stopped due to some interesting event in that thread, and so, we know that the stop_pc is valid. After running the testsuite I've seen no other situations where stop_pc is read uninitialised. There should be no user visible changes after this commit.
2021-09-08[gdb/build] Fix build with undefined CXX_STD_THREADTom de Vries1-7/+16
When building gdb on openSUSE Leap 42.3, we trigger the case that CXX_STD_THREAD is undefined, and run into: ... gdb/maint.c: In function 'void maintenance_show_worker_threads \ (ui_file*, int, cmd_list_element*, const char*)': gdb/maint.c:877:14: error: 'gdb::thread_pool' has not been declared gdb::thread_pool::g_thread_pool->thread_count ()); ^ Makefile:1647: recipe for target 'maint.o' failed make[1]: *** [maint.o] Error 1 ... Fix this by handling the undefined CXX_STD_THREAD case in maintenance_show_worker_threads, such that we get: ... $ gdb -q -batch -ex "maint show worker-thread" The number of worker threads GDB can use is 0. ... Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28312
2021-09-08sim: update configure target listMike Frysinger2-26/+29
Fix sorting of the list, and update the globs to match the list used in gdb's configure script.
2021-09-07gdb: cris: enable sim integrationMike Frysinger1-0/+1
The sim side is already ready to go for cris, so wire it up.
2021-09-07gdb: aarch64: enable sim integrationMike Frysinger1-0/+1
The sim side is already ready to go for aarch64, so wire it up.
2021-09-07gdb: sim: consolidate configure settingsMike Frysinger1-40/+35
Moving all the sim settings to one section makes it easier to track, and makes it easier to keep it aligned with the sim target tests. The gdb logic was duplicating this when handling different OS targets instead of having a single cpu check. Now it's more obvious that the sim is tied to a cpu and not related to the OS.
2021-09-08Automatic date update in version.inGDB Administrator1-1/+1
2021-09-07Remove unused declaration from gdbserver/win32-low.hTom Tromey1-3/+0
I noticed that gdbserver/win32-low.h has an unused declaration. This code was changed a while ago, but this declaration slipped through. This patch removes it. Tested by rebuilding.
2021-09-07gdb: make use of std::string in utils.cAndrew Burgess1-29/+25
Replace some of the manual string management (malloc/free) with std::string when creating commands in utils.c. Things are a little bit messy as, creating the prefix commands (using add_basic_prefix_cmd and add_show_prefix_cmd), doesn't copy the doc string, while creating the actual set/show commands (using add_setshow_enum_cmd) does copy the doc string. As a result, I have retained the use of xstrprintf when creating the prefix command doc strings, but switched to using std::string when creating the actual set/show commands. There should be no user visible changes after this commit.
2021-09-07Revert: [AArch64] MTE corefile supportLuis Machado6-27/+26
bfd * elf.c (elfcore_make_memtag_note_section): New function. (elfcore_grok_note): Handle NT_MEMTAG note types. binutils* readelf.c (get_note_type): Handle NT_MEMTAG note types. include * elf/common.h (NT_MEMTAG): New constant. (NT_MEMTAG_TYPE_AARCH_MTE): New constant.
2021-09-07gdb: use bool instead of int in struct internal_problemAndrew Burgess1-8/+21
Change struct internal_problem (gdb/utils.c) to use bool instead of int, update the 3 static instances of this structure that we create to use true/false instead of 1/0. I've also updated the comments on struct internal_problem as the existing comment doesn't seem to be referring to the structure, it talks about returning something, which doesn't make sense in this context. There should be no user visible changes after this commit.