summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Start working on reading .dmp filesusers/cbiesinger/minidumpChristian Biesinger2020-02-1424-13/+5748
| | | | Change-Id: I0cf39c48938b78ae3776d52f425133cadaa33de6
* gnulib: import count-one-bits module and use itSimon Marchi2020-02-1417-103/+303
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For a fix I intend to submit, I would need a function that counts the number of set bits in a word. There is __builtin_popcount that is supported by gcc and clang, but there is also a gnulib module that wraps that and provides a fallback for other compilers, so I think it would be good to use it. I also noticed that there is a bitcount function in arch/arm.c, so I thought that as a first step I would replace that one with the gnulib count-one-bits module. This is what this patch does. The gnulib module provides multiple functions, with various parameter length (unsigned int, unsigned long int, unsigned long long int), I chose the one that made sense for each call site based on the argument type. gnulib/ChangeLog: * update-gnulib.sh (IMPORTED_GNULIB_MODULES): Import count-one-bits module. * configure: Re-generate. * aclocal.m4: Re-generate. * Makefile.in: Re-generate. * import/count-one-bits.c: New file. * import/count-one-bits.h: New file. * import/Makefile.am: Re-generate. * import/Makefile.in: Re-generate. * import/m4/gnulib-cache.m4: Re-generate. * import/m4/gnulib-comp.m4: Re-generate. * import/m4/count-one-bits.m4: New file. gdb/ChangeLog: * arm-tdep.c: Include count-one-bits.h. (cleanup_block_store_pc): Use count_one_bits. (cleanup_block_load_pc): Use count_one_bits. (arm_copy_block_xfer): Use count_one_bits. (thumb2_copy_block_xfer): Use count_one_bits. (thumb_copy_pop_pc_16bit): Use count_one_bits. * arch/arm-get-next-pcs.c: Include count-one-bits.h. (thumb_get_next_pcs_raw): Use count_one_bits. (arm_get_next_pcs_raw): Use count_one_bits_l. * arch/arm.c (bitcount): Remove. * arch/arm.h (bitcount): Remove.
* Return unique_xmalloc_ptr from call_site_find_chainTom Tromey2020-02-144-19/+22
| | | | | | | | | | | | | | | | call_site_find_chain returns a pointer that the caller must deallocate. It seemed better here to return a unique_xmalloc_ptr instead. gdb/ChangeLog 2020-02-14 Tom Tromey <tromey@adacore.com> * dwarf2/frame-tailcall.c (dwarf2_tailcall_sniffer_first): Update. * dwarf2/loc.h (call_site_find_chain): Return unique_xmalloc_ptr. * dwarf2/loc.c (call_site_find_chain_1): Return unique_xmalloc_ptr. (call_site_find_chain): Likewise.
* Remove the old movsx and movzx documentation for AT&T syntaxH.J. Lu2020-02-142-16/+5
| | | | | * doc/c-i386.texi: Remove the old movsx and movzx documentation for AT&T syntax.
* Remove Intel syntax comments on movsx and movzxH.J. Lu2020-02-142-3/+7
| | | | | | | | Since movsx and movzx are valid mnemonic in AT&T syntax, remove Intel syntax comments on movsx and movzx to avoid confusing other readers. * i386-opc.tbl (movsx): Remove Intel syntax comments. (movzx): Likewise.
* x86: replace adhoc (partly wrong) ambiguous operand checking for MOVSX/MOVZXJan Beulich2020-02-1432-205/+1694
| | | | | | | | | | | | | | | | | | | | | | | | For these to get treatment consistent with other operand size checking the special logic shouldn't live in md_assemble(), but process_suffix(). And there's more logic involved than simply zapping the suffix. Note however that MOVS[BW]* and MOVZ[BW]* still won't be fully consistent, due to the objection to fold MOVS* templates just like was done for MOVZ* in c07315e0c6 ("x86: allow suffix-less movzw and 64-bit movzb"). Note further that it is against my own intentions to have MOVSX/MOVZX silently default to a byte source in AT&T mode. This should happen only when the destination register is a 16-bit one. In all other cases there is an ambiguity, and the user should be warned. But it was explicitly requested for this to be done in a way inconsistent with everything else. Note finally that the assembler change points out (and this patch fixes) a wrong Intel syntax test introduced by bc31405ebb2c ("x86-64: Properly encode and decode movsxd"): When source code specifies a 16-bit destination register, disassembly expectations shouldn't have been to find a 32-bit one.
* x86: adjust segment override prefix emissionJan Beulich2020-02-144-6/+29
| | | | | | | Since we already suppress the prefix altogether when it's the default one for the chosen addressing mode, let's do so also when instruction prefix and override specified with the memory operand match. (Note that insn prefix specified segment overrides never get discarded.)
* x86: optimize away pointless segment overridesJan Beulich2020-02-144-3/+31
| | | | | When optimizing there's no point keeping the segment overrides when we warn about their presence in the first place.
* x86: extend LEA's segment override warningJan Beulich2020-02-146-3/+33
| | | | | | For one both possible forms should be warned about. And then, to guard against future surprises, qualify the original opcode check by excluding VEX/EVEX-like templates.
* x86: Document movsx/movsxd/movzx for AT&T syntaxH.J. Lu2020-02-142-0/+59
| | | | | | | | Document different mnemonics of movsx, movsxd and movzx in AT&T syntax. PR gas/25438 * doc/c-i386.texi: Document movsx, movsxd and movzx for AT&T syntax.
* Fix argv[] in programs invoked by gdbserver on MS-WindowsEli Zaretskii2020-02-142-18/+33
| | | | | | | | | | gdbserver/ChangeLog 2020-02-14 Eli Zaretskii <eliz@gnu.org> * win32-low.c (create_process): Prepend PROGRAM to ARGS when preparing the command line for CreateProcess. (win32_create_inferior): Reflect the program name in debugging output that shows the process and its command line.
* [gdb] Speedup lnp_state_machine::handle_special_opcodeRichard Biener2020-02-142-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | I see for some program at gdb startup: ... Samples: 102K of event 'cycles:pu', Event count (approx.): 91710925103 Overhead Command Shared Object Symbol 15.21% gdb gdb [.] lnp_state_machine::handle_special ... where the divisions are the places we stall. The following micro-optimizes things but it smells like m_line_header->line_range is constant, likewise probably m_line_header->maximum_ops_per_instruction so eventually the divisions could be avoided completely with some lookup table. Well. Micro-optimizing with this patch improves things (don't expect [load] CSE over the gdbarch_adjust_dwarf2_line call). Build and reg-tested on x86_64-linux. gdb/ChangeLog: 2020-02-14 Richard Biener <rguenther@suse.de> * dwarf2/read.c (lnp_state_machine::handle_special_opcode): Apply CSE on expression with division operators.
* Automatic date update in version.inGDB Administrator2020-02-141-1/+1
|
* x86: Resolve PLT32 reloc aganst local symbol to sectionH.J. Lu2020-02-137-2/+62
| | | | | | | | | | | | | | | | | | Since PLT entry isn't needed for branch to local symbol, we can resolve R_386_PLT32/R_X86_64_PLT32 relocation aganst local symbol to section, similar to R_386_PC32/R_X86_64_PC32. 2020-02-13 Fangrui Song <maskray@google.com> H.J. Lu <hongjiu.lu@intel.com> PR gas/25551 * config/tc-i386.c (tc_i386_fix_adjustable): Don't check BFD_RELOC_386_PLT32 nor BFD_RELOC_X86_64_PLT32. * testsuite/gas/i386/i386.exp: Run relax-5 and x86-64-relax-4. * testsuite/gas/i386/relax-5.d: New file. * testsuite/gas/i386/relax-5.s: Likewise. * testsuite/gas/i386/x86-64-relax-4.d: Likewise. * testsuite/gas/i386/x86-64-relax-4.s: Likewise.
* gdbserver: rename source files to .ccSimon Marchi2020-02-1366-68/+75
| | | | | | | | | | | | | | For the same reasons outlined in the previous patch, this patch renames gdbserver source files to .cc. I have moved the "-x c++" switch to only those rules that require it. gdbserver/ChangeLog: * Makefile.in: Rename source files from .c to .cc. * %.c: Rename to %.cc. * configure.ac: Rename server.c to server.cc. * configure: Re-generate.
* gdbsupport: rename source files to .ccSimon Marchi2020-02-1340-133/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* [gdb/testsuite] Remove stale exec in gdb_compile_adaTom de Vries2020-02-132-0/+6
| | | | | | | | | | | | | | | | | | | | | | | When running test-case gdb.ada/ptype_tagged_param.exp, I get: ... PASS: gdb.ada/ptype_tagged_param.exp: compilation foo.adb ... However, when I then de-install gnatmake and run again, I get the same result. This is due to a stale exec. After removing the stale exec, I get: ... UNSUPPORTED: gdb.ada/ptype_tagged_param.exp: compilation foo.adb ... Fix this removing the stale exec in gdb_compile_ada before compilation. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-02-13 Tom de Vries <tdevries@suse.de> * lib/ada.exp (gdb_compile_ada): Delete stale exec before compilation.
* [gdb/testsuite] Add unsupported tests in catch_ex_std.expTom de Vries2020-02-132-0/+17
| | | | | | | | | | | | | | | | | | | | | | | If I de-install gnatbind, I run into: ... FAIL: gdb.ada/catch_ex_std.exp: gnatbind foo ... Fix this by marking the test unsupported instead: ... UNSUPPORTED: gdb.ada/catch_ex_std.exp: gnatbind foo ... Likewise for gnatlink. Tested on x86_64-linux, with and without gnatbind/gnatlink installed. gdb/testsuite/ChangeLog: 2020-02-13 Tom de Vries <tdevries@suse.de> * gdb.ada/catch_ex_std.exp: Indicate unsupported if gnatbind/gnatlink are missing.
* plugin: Search bfd-plugins directories only onceH.J. Lu2020-02-132-39/+50
| | | | | | | | | | | | | | | | | try_load_plugin is updated to take either plugin name or plugin entry. load_plugin is updated to search bfd-plugins directories first to build a list of plugins and call try_load_plugin with each plugin on the list. When --plugin is used, the plugin list only has one entry. * plugin.c (try_load_plugin): Make plugin_list_iter an argument and use it if it isn't NULL. Remove has_plugin_p argument. Add a build_list_p argument. Don't search plugin_list. Short circuit when building the plugin list. (has_plugin): Renamed to has_plugin_list. (bfd_plugin_set_plugin): Don't set has_plugin. (bfd_plugin_specified_p): Check plugin_list instead. (build_plugin_list): New function. (load_plugin): Call build_plugin_list and use plugin_list.
* Adding myself to gdb/MAINTAINERSAlok Kumar Sharma2020-02-132-0/+5
| | | | | | | | 2020-02-13 Alok Kumar Sharma <AlokKumar.Sharma@amd.com> * MAINTAINERS (Write After Approval): Adding myself. Change-Id: I2e6095a63247902f5fe23d58c2df8f995e41cf58
* x86: fix SSE4a dependencies of ".arch .nosse*"Jan Beulich2020-02-135-5/+27
| | | | | | Since ".arch .sse4a" enables SSE3 and earlier, disabling SSE3 should also disable SSE4a. And as per its name, ".arch .nosse4" should also do so.
* [gdb/testsuite] Fix gnatmake_version_at_leastTom de Vries2020-02-132-1/+8
| | | | | | | | | | | | | | | | | | | | | | | After de-installing gnatmake, I get: ... Running src/gdb/testsuite/gdb.ada/rename_subscript_param.exp ... ERROR: tcl error sourcing src/gdb/testsuite/gdb.ada/rename_subscript_param.exp. ERROR: couldn't execute "gnatmake": no such file or directory while executing "exec $gnatmake --version" (procedure "gnatmake_version_at_least" line 4) ... Fix this by wrapping the exec call in a catch call. Tested with and withouth gnatmake installed on x86_64-linux. gdb/testsuite/ChangeLog: 2020-02-13 Tom de Vries <tdevries@suse.de> * lib/ada.exp (gnatmake_version_at_least): Wrap exec call in a catch call.
* Remove some dead code from event-loop.cTom Tromey2020-02-122-33/+5
| | | | | | | | | | | | | | This removes some dead code from event-loop.c. This patch is from my old series to merge the gdb and gdbserver event loops; but since it is just removing dead code, it seemed simple to commit it separately. gdb/ChangeLog 2020-02-12 Tom Tromey <tom@tromey.com> * event-loop.c (event_data, gdb_event, event_handler_func): Remove.
* Automatic date update in version.inGDB Administrator2020-02-131-1/+1
|
* Move the frame data to the BFD when possibleTom Tromey2020-02-122-5/+42
| | | | | | | | | | | | | | | | | | | | | Now that comp_unit and the remaining frame data are all independent of the objfile, it can all be stored on the BFD and shared across inferiors. As with other code doing this same thing, care must be taken to not share the data when the objfile requires relocations. So, two keys are used: one for the BFD and one for the objfile, and gdb_bfd_requires_relocations is used to differentiate between the two cases. gdb/ChangeLog 2020-02-12 Tom Tromey <tom@tromey.com> * dwarf2/frame.c (dwarf2_frame_bfd_data): New global. (dwarf2_frame_objfile_data): Add comment. (find_comp_unit, set_comp_unit): New functions. (dwarf2_frame_find_fde): Use find_comp_unit. (dwarf2_build_frame_info): Use set_comp_unit.
* Remove the objfile backlink from comp_unitTom Tromey2020-02-122-13/+23
| | | | | | | | | | | | | | | | | This removes the objfile backlink from comp_unit. The only remaining uses involved fetching the text offset from the objfile. However, this is already conveniently computed at all the sites that call execute_cfa_program, and so it can simply be passed in. gdb/ChangeLog 2020-02-12 Tom Tromey <tom@tromey.com> * dwarf2/frame.c (struct comp_unit) <objfile>: Remove. (comp_unit): Don't initialize objfile. (execute_cfa_program): Add text_offset parameter. (execute_cfa_program_test, dwarf2_fetch_cfa_info) (dwarf2_frame_cache): Update. (dwarf2_build_frame_info): Don't set "objfile" member.
* Remove a use of the comp_unit backlinkTom Tromey2020-02-122-8/+20
| | | | | | | | | | | | | | | The DWARF frame comp_unit object still has a backlink to the objfile. In order to be truly objfile-independent, this must be removed. This patch removes one such use, by passing the gdbarch to decode_frame_entry directly. gdb/ChangeLog 2020-02-12 Tom Tromey <tom@tromey.com> * dwarf2/frame.c (decode_frame_entry_1): Add gdbarch parameter. (decode_frame_entry): Likewise. (dwarf2_build_frame_info): Update.
* Add per-unit obstackTom Tromey2020-02-122-2/+10
| | | | | | | | | | | | | | | This adds an auto_obstack to the DWARF frame comp_unit object, and then changes the remaining code here to use the comp_unit obstack rather than the objfile obstack. At this point, all the storage for frame data is self-contained -- that is, it is independent of the objfile. gdb/ChangeLog 2020-02-12 Tom Tromey <tom@tromey.com> * dwarf2/frame.c (struct comp_unit) <obstack>: New member. (decode_frame_entry_1): Use the comp_unit obstack.
* Store the comp_unit instead of the FDE tableTom Tromey2020-02-122-25/+34
| | | | | | | | | | | | | | | | | | | This changes the DWARF frame code to store the comp_unit on the objfile, rather than storing the FDE table. It also changes the comp_unit to be heap-allocated using "new". This change makes it simpler for a later patch to add a field to the comp_unit, and to have deallaction work properly. This in turn is important for making the frame data be independent of the objfile. gdb/ChangeLog 2020-02-12 Tom Tromey <tom@tromey.com> * dwarf2/frame.c (struct comp_unit): Add initializers and constructor. (dwarf2_frame_objfile_data): Store a comp_unit. (dwarf2_frame_find_fde): Update. (dwarf2_build_frame_info): Use "new".
* Change fde table to a vectorTom Tromey2020-02-122-115/+70
| | | | | | | | | | | | | | | This removes struct dwarf2_fde_table, replacing it with a typedef of std::vector. This simplifies the code somewhat. gdb/ChangeLog 2020-02-12 Tom Tromey <tom@tromey.com> * dwarf2/frame.c (struct dwarf2_fde_table): Remove. (dwarf2_fde_table): Typedef for std::vector. (dwarf2_frame_objfile_data): Remove the deleter. Now static. (dwarf2_frame_find_fde, add_fde, decode_frame_entry_1) (decode_frame_entry): Update. (dwarf2_build_frame_info): Use "new".
* Change booleans to bool in ARM's gdbarch_tdepChristian Biesinger2020-02-123-18/+27
| | | | | | | | | | | gdb/ChangeLog: 2020-02-12 Christian Biesinger <cbiesinger@google.com> * arm-tdep.c (arm_gdbarch_init): Update. * arm-tdep.h (struct gdbarch_tdep) <have_fpa_registers, have_wmmx_registers, have_vfp_pseudos, have_neon_pseudos, have_neon, is_m>: Change to bool.
* Print more information in arm_dump_tdepChristian Biesinger2020-02-122-0/+18
| | | | | | | | | | | I am keeping the (int) casts because a future patch will change the type to bool. gdb/ChangeLog: 2020-02-12 Christian Biesinger <cbiesinger@google.com> * arm-tdep.c (arm_dump_tdep): Print more fields of tdep.
* Remove dwarf_expr_batonTom Tromey2020-02-122-9/+4
| | | | | | | | | | | The type dwarf_expr_baton is unused and can be removed. gdb/ChangeLog 2020-02-12 Tom Tromey <tom@tromey.com> * dwarf2/loc.c (struct dwarf_expr_baton): Remove. Change-Id: Id8342da31398b9b4b08f31be7c3d612e9590bbbf
* Fix kill of processes created by win32_create_inferiorHannes Domani2020-02-122-0/+7
| | | | | | | | | | | | | | | | | handle_v_kill uses signal_pid because win32 doesn't support multi-process. Without this gdb just refuses to kill the process: (gdb) kill Kill the program being debugged? (y or n) y Sending packet: $vKill;a410#33...Packet received: E01 Packet vKill (kill) is supported Can't kill process gdbserver/ChangeLog: 2020-02-12 Hannes Domani <ssbssa@yahoo.de> * win32-low.c (win32_create_inferior): Set signal_pid.
* Cache the Thread Local Base pointer type in the gdbarchHannes Domani2020-02-122-8/+12
| | | | | | | | | gdb/ChangeLog: 2020-02-12 Hannes Domani <ssbssa@yahoo.de> * windows-tdep.c (struct windows_gdbarch_data): Add tib_ptr_type. (windows_get_tlb_type): Use windows_gdbarch_data->tib_ptr_type.
* x86: correct VFPCLASSP{S,D} operand size handlingJan Beulich2020-02-129-9/+137
| | | | | | | | | | | | With AVX512VL disabled (e.g. when writing code for the Knights family of processors) these insns aren't ambiguous when used with a memory source, and hence should be accepted without suffix or operand size specifier. When AVX512VL is enabled, to be consistent with this as well as other ambiguous operand size handling it would seem better to just warn about the ambiguity in AT&T mode, and still default to 512-bit operands (on the assumption that the code may have been written without AVX512VL in mind yet), but it was requested to leave AT&T syntax mode alone here.
* x86: fold two JMP templatesJan Beulich2020-02-123-16/+8
| | | | | | | | Now that the AMD64 check in match_template() applies to 64-bit code only, the non-64-bit and the Amd64 template can be folded, as being otherwise compatible with one another. (Oddly enough the same doesn't apply to CALL, due to the suffixes it permits, while JMP doesn't allow for any.)
* x86-64: Intel64 adjustments for insns dealing with far pointersJan Beulich2020-02-1215-28/+224
| | | | | | | AMD and Intel differ in their handling of far indirect branches as well as LFS/LGS/LSS: AMD CPUs ignore REX.W while Intel ones honors it. (Note how the latter three were hybrids so far, while far branches were fully AMD-like.)
* Disable gdbserver on host != target configurationsMaciej W. Rozycki2020-02-122-2/+16
| | | | | | | | | | | | | | | | Correct fallout from commit 919adfe84092 ("Move gdbserver to top level") and revert to not building `gdbserver' in a cross-configuration, that is where host != target, matching the documented behaviour. We have no way to support non-native `gdbserver', and native `gdbserver' is usually of no use with cross-GDB of the chosen host. gdbserver/ChangeLog: 2020-02-12 Maciej W. Rozycki <macro@wdc.com> Pedro Alves <palves@redhat.com> Skip building gdbserver in a cross-configuration. * configure.srv: Set $gdbserver_host depending on whether $target is $host. Use $gdbserver_host instead of $host.
* [gdb] Fix -Wstrict-null-sentinel warning (--with-iconv-bin)Tom de Vries2020-02-121-1/+2
| | | | | | | | | | | | | | | | | | | | When using configure flag --with-iconv-bin=$(which iconv), we run into: ... gdb/charset.c: In function 'void find_charset_names()': gdb/charset.c:821:75: error: missing sentinel in function call [-Werror=format=] iconv_program = concat (iconv_dir.c_str(), SLASH_STRING, "iconv", NULL); ^ cc1plus: all warnings being treated as errors ... Fix the warning. Build and reg-tested on x86_64-linux. 2020-02-12 Lukas Durfina <ldurfina@tachyum.com> Tom de Vries <tdevries@suse.de> * charset.c (find_charset_names): Cast concat NULL sentinel to char *.
* x86: also disallow non-byte/-word registers with byte/word suffixJan Beulich2020-02-127-71/+62
| | | | | | Along the lines of be4c5e58bd ("x86: Always disallow double word suffix with word general register") also adjust check_{byte,word}_reg(), to make overall behavior consistent again in this regard.
* x86/Intel: improve diagnosticsJan Beulich2020-02-122-4/+11
| | | | | | | The diagnostics issued by check_*_reg() are pretty AT&T-centric. Re-use logic already used for SIMD memory operand size checking also for ones where GPRs would alternatively also be allowed. (There's certainly room for further improvement here.)
* Update a comment in psymtab.hTom Tromey2020-02-112-1/+7
| | | | | | | | | | | This updates a comment in psymtab.h to reflect the current reality. gdb/ChangeLog 2020-02-11 Tom Tromey <tom@tromey.com> * psymtab.h: Update comment. Change-Id: I438bb5929c3ebd1a4c6e9a902490f2ef63014ab3
* Don't allow copying of auto_obstackTom Tromey2020-02-112-0/+7
| | | | | | | | | | | | | | Add DISABLE_COPY_AND_ASSIGN to struct auto_obstack, to prevent copying it. Copying an auto_obstack would be a bug. 2020-02-11 Tom Tromey <tom@tromey.com> * gdb_obstack.h (struct auto_obstack): Use DISABLE_COPY_AND_ASSIGN. Change-Id: Ic9e5ab20acfcfa61c241fed4d99bbb1caefba3cd
* Don't forward-declare struct objfile in dwarf2/frame.hTom Tromey2020-02-112-1/+4
| | | | | | | | | | | | dwarf2/frame.h forward-declares struct objfile, but there's no need for this. gdb/ChangeLog 2020-02-11 Tom Tromey <tom@tromey.com> * dwarf2/frame.h (struct objfile): Don't forward declare. Change-Id: I4d54d46ac9422eeb64dc5f0b934792e77a875aa5
* Automatic date update in version.inGDB Administrator2020-02-121-1/+1
|
* Plugin: Treat each object as independentH.J. Lu2020-02-112-38/+45
| | | | | | | | | | Since plugin treats each object as independent, we must do a fresh dlopen of plugin for each object. PR binutils/25355 * plugin.c (try_claim): Always clean up for LTO wrapper. (try_load_plugin): Treat each object as independent. Create a copy for plugin name.
* Remove use of deprecated_add_core_fns in cris_tdep.cChristian Biesinger2020-02-112-43/+37
| | | | | | | | | | | | | | | | | | | | | | | | | The non-deprecated equivalent is implementing the gdbarch function iterate_over_regset_sections, this patch does that. Tested by generating a core file on cris under qemu and comparing the output of "info registers". This also fixes this warning when loading cris core files: warning: Unexpected size of section `.reg/164' in core file. gdb/ChangeLog: 2020-02-11 Christian Biesinger <cbiesinger@google.com> * cris-tdep.c (cris_supply_gregset): Change signature to match what struct regset expects. (cris_regset): New struct. (fetch_core_registers): Remove. (cris_iterate_over_regset_sections): New function. (_initialize_cris_tdep): Don't call deprecated_add_core_fns. (cris_gdbarch_init): Call set_gdbarch_iterate_over_regset_sections. Change-Id: Ieef895b5a2fdc797d1a913cd1c0c07563edfe8e7
* New testcase for PR tui/25126 (staled source cache)Sergio Durigan Junior2020-02-113-0/+148
| | | | | | | | | | | | | | | | | | | | | | | | | | I'm dealing with a Fedora GDB bug that is related to PR tui/25126, and I thought I'd write a specific testcase for it because I couldn't find one. The idea is to get the simple reproducer from the bug and tweak the testcase around it. This one was a bit hard because, since we need to modify the source file and recompile it, it involved a bit of TCL-foo to do things. Also for this reason, I'm only enabling the test for native boards. I tested this with an upstream GDB and made sure everything is passing. I also tested with a faulty GDB and made sure the test failed. gdb/testsuite/ChangeLog: 2020-02-11 Sergio Durigan Junior <sergiodj@redhat.com> PR tui/25126 https://bugzilla.redhat.com/show_bug.cgi?id=1784210 * gdb.base/cached-source-file.c: New file. * gdb.base/cached-source-file.exp: New file. Change-Id: Ib1b074342ebe8613c6d1dfde631691ebdf6d81c6
* Add a comment for the ARM_F{0..7}_REGNUM registersChristian Biesinger2020-02-112-0/+6
| | | | | | | | | | | | | These are for the obsolete FPA architecture. gdb/ChangeLog: 2020-02-11 Christian Biesinger <cbiesinger@google.com> * arch/arm.h (enum gdb_regnum): Add comment for the FP0..7 registers. Change-Id: I6920616318ee637493d4ca12b91fa2ebcd103d76