aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-11-06Add support for a couple of new Mach-O commands.Nick Clifton4-1/+17
PR 23742 * mach-o.c (bfd_mach_o_read_command): Accept and ignore BFD_MACH_O_LC_LINKER_OPTIONS and BFD_MACH_O_LC_BUILD_VERSION commands. * mach-o/loader.h: Add BFD_MACH_O_LC_BUILD_VERSION.
2018-11-06[arm] fix testsuite breakage on pe-coffMatthew Malcomson2-2/+8
The PE target can insert NOP's for padding to 4 byte alignment. This was causing a testcase failure, this commit fixes the testcase. This commit also escapes some full-stops in the testcase regexp. 2018-11-06 Matthew Malcomson <matthew.malcomson@arm.com> * testsuite/gas/arm/neon-cond-bad_t2.d: Fix testcase for PE target.
2018-11-06[arm] Check for neon and condition in vcvt.f16.f32Matthew Malcomson7-14/+40
VCVT between f16 and f32 is an Advanced SIMD instruction. Not all the VCVT alternatives need neon, hence the check for neon is in the encode function. The check on neon for VCVT.f16.f32 (and vice versa) is missing. vshcmd: > echo 'vcvt.f16.f32 d1, q1' | gas/as-new -mfpu=vfpxd -march=armv8.5-a - testdir [15:59:10] $ Also, the handling of the condition code behaves differently to other SIMD instructions -- no error message is produced when assembling an instruction with a condition code suffix despite the arm encoding not allowing a condition code. (n.b. the actual binary produced is independent of the suffix). The instruction should be treated similarly to VSUBL that has the same caveat of "must be unconditional" describing the {<c>} symbol. vcvt half-precision to single precision found in F6.1.58 in the ARM Architecture Reference Manual issue C.a, vsubl found in F6.1.240 in the ARM Architecture Reference Manual issue C.a 2018-11-06 Matthew Malcomson <matthew.malcomson@arm.com> * config/tc-arm.c (do_neon_cvt_1): Add check for neon and condition codes to half-precision conversion. * testsuite/gas/arm/neon-cond-bad-inc.s: Check vcvteq disallowed. * testsuite/gas/arm/neon-cond-bad.l: Likewise. * testsuite/gas/arm/neon-cond-bad_t2.d: Check vcvteq allowed in IT block. * testsuite/gas/arm/vfp-bad.l: Ensure vcvt doesn't work without neon. * testsuite/gas/arm/vfp-bad.s: Likewise.
2018-11-06[BINUTILS, ARM] Add Armv8.5-A to select_arm_features and update macros.Sudakshina Das4-9/+19
This patch addresses the following 1) Adding ARMv8.5-A in select_arm_features. 2) Updating the feature macro so that the new ARM_EXT2_* features for Armv8.5-A are moved to ARM_AEXT2_V8_5A. *** opcodes/ChangeLog *** 2018-11-06 Sudakshina Das <sudi.das@arm.com> * arm-dis.c (select_arm_features): Update bfd_mach_arm_8 with Armv8.5-A. Remove reduntant ARM_EXT2_FP16_FML. *** include/ChangeLog *** 2018-11-06 Sudakshina Das <sudi.das@arm.com> * opcode/arm.h (ARM_ARCH_V8_5A): Move ARM_EXT2_PREDRES and ARM_EXT2_SB to ... (ARM_AEXT2_V8_5A): Here.
2018-11-06PowerPC instruction mask checksAlan Modra4-155/+101
The instruction mask bits should never overlap any of the operands, nor should operand bits overlap, but some operands weren't checked. This patch arranges to check the omitted operands, using a mask returned by the operand->insert function. Some tweaking of various insert functions is needed to support this: The error case must set field bits. Since I was looking at the insert functions, I tidied some dead code and simplified some of the powerpc_operands entries. gas/ * config/tc-ppc.c (insn_validate): Don't ignore mask in PPC_OPSHIFT_INV case. Call the insert function to calculate a mask. opcodes/ * ppc-opc.c (insert_arx, insert_ary, insert_rx, insert_ry, insert_ls), (insert_evuimm1_ex0, insert_evuimm2_ex0, insert_evuimm4_ex0), (insert_evuimm8_ex0, insert_evuimm_lt8, insert_evuimm_lt16), (insert_rD_rS_even, insert_off_lsp, insert_off_spe2, insert_Ddd): Don't return zero on error, insert mask bits instead. (insert_sd4h, extract_sd4h, insert_sd4w, extract_sd4w): Delete. (insert_sh6, extract_sh6): Delete dead code. (insert_sprbat, insert_sprg): Use unsigned comparisions. (powerpc_operands <OIMM>): Set shift count rather than using PPC_OPSHIFT_INV. <SE_SDH, SE_SDW>: Likewise. Don't use insert/extract functions.
2018-11-06PowerPC instruction operand flag validationAlan Modra2-0/+14
This adds another check that might have saved me a little time recently if it had been present. * config/tc-ppc.c (insn_validate): Check that optional operands are not followed by non-optional operands.
2018-11-06x86: correctly handle VPBROADCASTD with EVEX.W set outside of 64-bit modeJan Beulich6-1/+16
For the flavor having a GPR operand EVEX.W is ignored outside of 64-bit mode. The mnemonic should therefore not be VPBROADCASTQ.
2018-11-06x86: correctly handle VMOVD with EVEX.W set outside of 64-bit modeJan Beulich7-14/+28
For the flavors having a GPR operand EVEX.W is ignored outside of 64-bit mode. The mnemonic should therefore not be KMOVQ, the GPR operand should not name a non-existing 64-bit register, just like is already the case for the AVX counterparts, and the Disp8 scaling factor should be 4 rather than 8.
2018-11-06x86: correctly handle KMOVD with VEX.W set outside of 64-bit modeJan Beulich5-32/+26
For the flavors having a GPR operand VEX.W is ignored outside of 64-bit mode. The mnemonic should therefore not be KMOVQ.
2018-11-06x86: adjust {,E}VEX.W handling for PEXTR* / PINSR*Jan Beulich13-62/+107
PEXTR{B,W} and PINSR{B,W}, just like for AVX512BW, are WIG, no matter that the SDM uses a nonstandard description of that fact. PEXTRD, even with EVEX.W set, ignores that bit outside of 64-bit mode, just like its AVX counterpart.
2018-11-06x86: adjust {,E}VEX.W handling outside of 64-bit modeJan Beulich16-63/+280
Many VEX-/EVEX-encoded instructions accessing GPRs become WIG outside of 64-bit mode. The respective templates should specify neither VexWIG nor VexW0, but instead the setting of the bit should be determined from - REX.W in 64-bit mode, - the setting established through -mvexwig= / -mevexwig= otherwise. This implies that the evex-wig2 testcase needs to go away, as being wrong altogether. A few test additions desirable here will only happen in later patches, as the disassembler needs adjustments first. Once again SSE2AVX templates are left alone, for it being unclear what the behavior there should be.
2018-11-06x86: fix various non-LIG templatesJan Beulich13-86/+539
Quite a few templates were marked LIG while really the insns aren't. Introduce descriptive shorthands once again, instead of continuing to use the less legible original forms.
2018-11-06x86: allow {store} to select alternative {,}PEXTRW encodingJan Beulich8-13/+67
The 0F C5 encoding is indeed a load type one (just that memory operands are not permitted), while the 0F 3A 15 encoding is obviously a store. Allow the pseudo prefixes to be used to select between them. Also move (without any change) the secondary AVX512BW templates next to the primary one.
2018-11-06x86: add more VexWIGJan Beulich12-303/+363
Commits 6865c0435a ("x86: Support VEX/EVEX WIG encoding") and 6fa52824c3 ("x86: Replace VexW=3 with VexWIG") omitted quite a few templates, oddly enough in some cases despite testcases getting added (which then were recorded with wrong expected output). Also adjust VPMAXUB's attributes in the AVX512BW case to match ordering of that of neighboring templates. For the moment SSE2AVX templates are left alone, as it isn't clear whether they were intentionally left untouched by the original commits (the descriptions don't say either way). In this context I question the decision in commit 0375113302 ("x86: Add -mvexwig=[0|1] option to assembler") to move the logic to determine the value of the W bit ahead of the decision whether to use 2-byte VEX: While I can see this as one possible interpretation of -mvexwig=, the other alternative (setting the value of the bit only if it actually exists in the encoding) looks as reasonable to me, and perhaps even more in line with us generally trying to pick the shortest encoding.
2018-11-06x86: XOP VPHADD* / VPHSUB* are VEX.W0Jan Beulich3-32/+40
Also avoid introducing further uses of VexW=1, by introducing and using VexW0 at this occasion. Move the marker past all #define-s.
2018-11-06Automatic date update in version.inGDB Administrator1-1/+1
2018-11-05ChangeLog for 'Fix 4K leak each time next/step changes of function.'Philippe Waroquiers1-0/+6
2018-11-05Fix 4K leak in open_source_file each time next/step changes of function.Philippe Waroquiers1-1/+2
When current function changes after a next/step, GDB shows a message such as: (gdb) s info_fun1 () at /bd/home/philippe/gdb/git/build_smallthing/gdb/testsuite/../../../smallthing/gdb/testsuite/gdb.base/info_qt.c:41 41 info_qt_inc++; (gdb) Valgrind reports a 4K definite leak for each such message (full stacktrace of the leak below). This patch fixes this leak, by transferring the current s->fullname to the unique_xmalloc_ptr fullname given to find_and_open_source. Note that I do not understand why find_and_open_source always tries to re-execute the substitution rules on the provided fullname, as source.c symtab_to_fullname just blindly returns a non NULL s->fullname, counting on forget_cached_source_info to be called if search dir or substitution rules are changed. Similarly, psymtab_to_fullname also just returns a non NULL ps->fullname. ==15309== VALGRIND_GDB_ERROR_BEGIN ==15309== 69,632 bytes in 17 blocks are definitely lost in loss record 3,158 of 3,186 ==15309== at 0x4C2BE2D: malloc (vg_replace_malloc.c:299) ==15309== by 0x5BF0987: realpath@@GLIBC_2.3 (canonicalize.c:78) ==15309== by 0x41F713: gdb_realpath(char const*) (pathstuff.c:72) ==15309== by 0x608833: openp(char const*, enum_flags<openp_flag>, char const*, int, std::unique_ptr<char, gdb::xfree_deleter<char> >*) (source.c:861) ==15309== by 0x608B89: find_and_open_source(char const*, char const*, std::unique_ptr<char, gdb::xfree_deleter<char> >*) (source.c:1049) ==15309== by 0x608D0B: open_source_file(symtab*) (source.c:1074) ==15309== by 0x609101: print_source_lines_base(symtab*, int, int, enum_flags<print_source_lines_flag>) (source.c:1291) ==15309== by 0x614ADF: print_frame_info(frame_info*, int, print_what, int, int) (stack.c:911) ==15309== by 0x614C45: print_stack_frame(frame_info*, int, print_what, int) (stack.c:181) ==15309== by 0x511D5E: print_stop_location (infrun.c:8044) ==15309== by 0x511D5E: print_stop_event(ui_out*) (infrun.c:8061) ==15309== by 0x40DD6D: cli_on_normal_stop(bpstats*, int) (cli-interp.c:145) ==15309== by 0x512409: operator() (functional:2127) ==15309== by 0x512409: notify (observable.h:106) ==15309== by 0x512409: normal_stop() (infrun.c:8334) ==15309== by 0x5156D8: fetch_inferior_event(void*) (infrun.c:3955) ==15309== by 0x4B3EEC: gdb_wait_for_event(int) (event-loop.c:859) ==15309== by 0x4B3FF6: gdb_do_one_event() [clone .part.4] (event-loop.c:322) ==15309== by 0x4B41B4: gdb_do_one_event (common-exceptions.h:219) ==15309== by 0x4B41B4: start_event_loop() (event-loop.c:371) ==15309== by 0x551217: captured_command_loop() (main.c:330) ==15309== by 0x55220C: captured_main (main.c:1177) ==15309== by 0x55220C: gdb_main(captured_main_args*) (main.c:1193) ==15309== by 0x29B4F7: main (gdb.c:32) ==15309== ==15309== VALGRIND_GDB_ERROR_END gdb/ChangeLog 2018-11-04 Philippe Waroquiers <philippe.waroquiers@skynet.be> * source.c (open_source_file): Fix leak by transferring the current s->fullname to the unique_xmalloc_ptr fullname given to find_and_open_source.
2018-11-05Correct ChangeLog entries for PR gas/23854 commitH.J. Lu2-2/+2
commit e60f4d3bdac25f02875afe36b7436bc2dfbbb978 Author: H.J. Lu <hjl.tools@gmail.com> Date: Mon Nov 5 09:01:26 2018 -0800 x86: Disable GOT relaxation with data prefix Since linker GOT relaxation isn't valid for 16-bit GOT access, we should disable GOT relaxation with data prefix.
2018-11-05x86: Disable GOT relaxation with data prefixH.J. Lu10-7/+150
Since linker GOT relaxation isn't valid for 16-bit GOT access, we should disable GOT relaxation with data prefix. gas/ PR gas/r23854 * config/tc-i386.c (output_disp): Disable GOT relaxation with data prefix. * testsuite/gas/i386/mixed-mode-reloc32.d: Updated. ld/ PR gas/r23854 * testsuite/ld-i386/i386.exp: Run pr23854. * testsuite/ld-x86-64/x86-64.exp: Likewwise. * testsuite/ld-i386/pr23854.d: New file. * testsuite/ld-i386/pr23854.s: Likewwise. * testsuite/ld-i386/pr23854.d: Likewwise. * testsuite/ld-x86-64/pr23854.d: Likewwise. * testsuite/ld-x86-64/pr23854.s: Likewwise.
2018-11-05Automatic date update in version.inGDB Administrator1-1/+1
2018-11-04Return gdbpy_ref from gdbpy_get_varobj_pretty_printerTom Tromey4-24/+31
This changes gdbpy_get_varobj_pretty_printer to return a gdbpy_ref. gdb/ChangeLog 2018-11-04 Tom Tromey <tom@tromey.com> * varobj.c (install_default_visualizer): Update. * python/python-internal.h (gdbpy_get_varobj_pretty_printer): Return gdbpy_ref. * python/py-prettyprint.c (search_pp_list): Return gdbpy_ref. (find_pretty_printer_from_progspace) (find_pretty_printer_from_gdb, find_pretty_printer) (gdbpy_get_varobj_pretty_printer): Return gdbpy_ref. (gdbpy_get_varobj_pretty_printer, gdbpy_default_visualizer): Update.
2018-11-04Return gdbpy_ref from some Python string functionsTom Tromey9-29/+56
This changes python_string_to_unicode, python_string_to_target_python_string, and host_string_to_python_string to return gdbpy_ref. gdb/ChangeLog 2018-11-04 Tom Tromey <tom@tromey.com> * python/python.c (gdbpy_parameter_value): Update. * python/python-internal.h (python_string_to_unicode) (python_string_to_target_python_string) (host_string_to_python_string): Return gdbpy_ref. * python/py-utils.c (python_string_to_unicode) (unicode_to_encoded_python_string) (unicode_to_target_python_string) (python_string_to_target_string) (python_string_to_target_python_string): Return gdbpy_ref. (python_string_to_host_string): Update. (host_string_to_python_string): Return gdbpy_ref. * python/py-symtab.c (stpy_get_filename, stpy_get_producer) (stpy_fullname): Update. * python/py-progspace.c (pspy_get_filename, pspy_solib_name): Update. * python/py-prettyprint.c (print_string_repr): Update. * python/py-objfile.c (objfpy_get_filename, objfpy_get_username) (objfpy_get_build_id): Update. * python/py-breakpoint.c (bppy_get_location) (bppy_get_expression, bppy_get_condition, bppy_get_commands): Update.
2018-11-04Return gdbpy_ref from gdb_py_object_from_*longestTom Tromey7-21/+34
This changes gdb_py_object_from_longest and gdb_py_object_from_ulongest to return a gdbpy_ref rather than a PyObject*. gdb/ChangeLog 2018-11-04 Tom Tromey <tom@tromey.com> * python/python-internal.h (gdb_py_object_from_longest) (gdb_py_object_from_ulongest): Return gdbpy_ref. * python/py-value.c (valpy_int): Update. * python/py-utils.c (gdb_py_object_from_longest): Return gdbpy_ref. (gdb_py_object_from_ulongest): Likewise. * python/py-type.c (typy_get_alignof): Update. * python/py-linetable.c (ltpy_get_all_source_lines) (ltpy_entry_get_line, ltpy_entry_get_pc): Update. * python/py-block.c (blpy_get_start, blpy_get_end): Update.
2018-11-04Automatic date update in version.inGDB Administrator1-1/+1
2018-11-03elfedit: Move ELF header magic bytes check to get_file_headerH.J. Lu2-13/+11
Skip the file if ELF header magic bytes doesn't match. * elfedit.c (update_elf_header): Move EI_MAG? check to ... (get_file_header): Here.
2018-11-03OBVIOUS Fix a typo in ada-lang.c add_prefix_cmd for "set ada"Philippe Waroquiers2-1/+5
Correct typo in add_prefix_cmd doc arg for "set ada".
2018-11-03OBVIOUS Remove a useless const char *type and its initialization.Philippe Waroquiers2-3/+6
Valgrind detected a leak for the line: type = xstrdup ("auto"); as the compile probably dropped the type variable completely, as its only usage was this initialization. So, remove the useless variable.
2018-11-03OBVIOUS fix the month of the last gdb/ChangeLog entry to be 11 instead of 12.Philippe Waroquiers1-1/+1
2018-11-03Automatic date update in version.inGDB Administrator1-1/+1
2018-11-02binutils: Add AC_FUNC_MMAP to configure.acH.J. Lu4-2/+220
Add AC_FUNC_MMAP to configure.ac so that HAVE_MMAP will be checked in objdump.c and mmap is used if available. * configure.ac (AC_FUNC_MMAP): New. * config.in: Regenerated. * configure: Likewise.
2018-11-02(Ada) Add ravenscar tasking support on AArch64Joel Brobecker7-1/+266
This patch adds support for debugging Ravenscar tasks, similar to what is done for ppc and sparc. gdb/ChangeLog: * aarch64-ravenscar-thread.h, aarch64-ravenscar-thread.c: New files. * aarch64-tdep.c: #include "aarch64-ravenscar-thread.h". (aarch64_gdbarch_init): Add call to register_aarch64_ravenscar_ops. * Makefile.in (ALL_64_TARGET_OBS): Add aarch64-ravenscar-thread.o. (HFILES_NO_SRCDIR): Add aarch64-ravenscar-thread.h. (ALLDEPFILES): Add aarch64-ravenscar-thread.c. * configure.tgt (cpu_obs) [aarch64*-*-*]: Add ravenscar-thread.o and aarch64-ravenscar-thread.o. * NEWS: Add entry documenting Ravenscar tasking support on AArch64 ELF.
2018-11-02QUIET flag initialization missing in 2 places.Philippe Waroquiers3-2/+7
Fix by Matthew Malcomson <matthew.malcomson@arm.com> Pushed as obvious.
2018-11-02[GOLD] make cleanAlan Modra5-3/+24
Cleans a few more test files. * Makefile.am (MOSTLYCLEANFILES): Define. * Makefile.in: Regnerate. * testsuite/Makefile.am (MOSTLYCLEANFILES): Add ver_test_14 and gnu_property_test. * testsuite/Makefile.in: Regnerate.
2018-11-02Squash readelf warning on zero sh_link reloc sectionAlan Modra2-20/+26
On readelf examining a static executable built with current glibc, we get a silly warning. Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [ 0] NULL 0000000000000000 000000 000000 00 0 0 0 [ 1] .note.ABI-tag NOTE 0000000000400190 000190 000020 00 A 0 0 4 [ 2] .note.gnu.build-id NOTE 00000000004001b0 0001b0 000024 00 A 0 0 4 readelf: Warning: [ 3]: Link field (0) should index a symtab section. [ 3] .rela.plt RELA 00000000004001d8 0001d8 000228 18 AI 0 20 8 This .rela.plt section contains only IRELATIVE relocations (which have symbol index zero), so it isn't appropriate to warn. A zero sh_link section is deliberately chosen for such a section (see PR10337 and PR23850). So this patch disables the SHT_REL* sh_link warning. I've also removed the .rel.dyn/.rela.dyn section name test to disable the sh_info warning for SHT_REL* sections. While relocation sections in an executable need not specify the section they relocate (the relocation sh_offset field is an address, not a section offset), that isn't true in a relocatable file where sh_offset is relative to a section. If .rela.dyn happens to exist in an ET_REL object it must specify a valid section. * readelf.c (process_section_headers): Don't warn on a zero sh_info or sh_link for any reloc section in an executable or shared library. Do warn for .rel.dyn/.rela.dyn in ET_REL.
2018-11-02PR23850, strip should not discard/move .rela.plt in executableAlan Modra2-8/+17
strip/objcopy can't deal with alloc reloc sections, not .rela.dyn or .rela.plt in a dynamic executable, or .rela.plt/.rela.iplt in a static executable. So, don't have BFD treat them as side-channel data associated with the section they are relocating. PR 23850 * elf.c (bfd_section_from_shdr): Treat SHF_ALLOC SHT_REL* sections in an executable or shared library as normal sections.
2018-11-01RISC-V: Don't allow unaligned breakpoints.Jim Wilson2-8/+30
Some hardware doesn't support unaligned accesses, and a bare metal target may not have an unaligned access trap handler. So if the PC is 2-byte aligned, then use a 2-byte breakpoint to avoid unaligned accesses. Tested on native RV64GC Linux with gdb testsuite and cross on spike simulator and openocd with riscv-tests/debug. gdb/ * riscv-tdep.c (riscv_breakpoint_kind_from_pc): New local unaligned_p. Set if pcptr if unaligned. Return 2 if unaligned_p true. Update debugging messages.
2018-11-02Automatic date update in version.inGDB Administrator1-1/+1
2018-11-01(Ada) fix "error in expression" when using watch -location commandJoel Brobecker7-1/+129
The "watch -l EXPR" command with the language set to Ada currently fails with the following error: (gdb) watch -l global_var Error in expression, near ` 0x000000000062d2d8'. The error occurs because GDB internally translate the request into a watchpoint on a different expression: "* (TYPE *) ADDR" where TYPE and ADDR are the type and the address of the object returned by the expression's evaluation (resp.). So, in the example above, global_var being an integer stored at 0x000000000062d2d8, GDB tries to set a watchpoint on "* (integer *) 0x000000000062d2d8", which fails, because we try to parse this expression with Ada, when in fact it is not valid. This patch fixes the issue by implementing the la_watch_location_expression language method, using a syntax that the Ada parser recognizes ("{TYPE} ADDR"). gdb/ChangeLog: * ada-lang.c (ada_watch_location_expression): New function. (ada_language_defn): Set la_watch_location_expression to ada_watch_location_expression. gdb/testsuite/ChangeLog: * gdb.ada/watch_minus_l: New testcase.
2018-11-01remove trailing spaces in print-utils.c ("int_string" function)Joel Brobecker2-3/+7
gdb/ChangeLog: * print-utils.c (int_string): Remove unnecessary trailing spaces.
2018-11-01gdb.texinfo: Fix the output of the "info tasks 2" exampleJoel Brobecker2-1/+7
gdb/doc/ChangeLog: * gdb.texinfo (Ada Tasks): Update the "info task 2" example output to match the current implementation.
2018-11-01rs6000-tdep.c:skip_prologue avoid negative left shiftJoel Brobecker2-4/+12
the rs6000-tdep.c::skip_prologue function has the following code: unsigned int all_mask = ~((1U << fdata->saved_gpr) - 1); /* Not a recognized prologue instruction. Handle optimizer code motions into the prologue by continuing the search if we have no valid frame yet or if the return address is not yet saved in the frame. Also skip instructions if some of the GPRs expected to be saved are not yet saved. */ if (fdata->frameless == 0 && fdata->nosavedpc == 0 && (fdata->gpr_mask & all_mask) == all_mask) break; The problem is that fdata->saved_gpr is initialized to -1, and so, if no instruction is found in the function's prologue that causes us to set that field to a non-negative value, the sanitizer crashes with the following message: rs6000-tdep.c:1965:34: runtime error: shift exponent -1 is negative This patch fixes the issue the by only doing the shift if saved_gpr is not negative. When saved_gpr is negative, we actually don't need the shift. gdb/ChangeLog: * rs6000-tdep.c (skip_prologue): Fix potential negative left shifting. Tested on ppc-linux native. Also tested on ppc-elf (baremetal) using AdaCore's testsuite.
2018-11-01arm-pikeos: software single stepJerome Guitton6-0/+106
On ARM, PikeOS does not support hardware single step, causing various semi-random errors when trying to next/step over some user code. So this patch changes this target to use software-single-step instead. The challenge is that, up to now, the PikeOS target was in all respects identical to a baremetal target as far as GDB was concerned, meaning we were using the baremetal osabi for this target too. This is no longer possible, and we need to introduce a new OSABI variant. Unfortunately, there isn't anything in the object file that would allow us to differentiate between the two platforms. So we have to rely on a heuristic instead, where we look for some known symbols that are required in a PikeOS application (these symbols are expected to be defined by the default linker script, and correspond to routines used to allocate the application stack). For the long run, the hope is that the stub implementation provided by PikeOS is enhanced so that it includes vContSupported+ to the $qSupported query, and then that the reply to the "vCont?" query only return support for "continue" operations (thus exclusing "step" operations). We could then use that information to reliably determine at connection time that the target does not support single-stepping and therefore automatically turn software single-stepping automatically based on it. gdb/ChangeLog: * defs.h (enum gdb_osabi): Add GDB_OSABI_PIKEOS. * osabi.c (gdb_osabi_names): Add name for GDB_OSABI_PIKEOS. * arm-pikeos-tdep.c: New file. * configure.tgt: Add arm-pikeos-tdep.o to the case of ARM embedded system. * Makefile.in (ALL_TARGET_OBS): Add arm-pikeos-tdep.o. Tested on arm-pikeos and arm-elf using AdaCore's testsuite. We also evaluated it on armhf-linux as a cross platform.
2018-11-01Import mkdtemp gnulib module, fix mingw buildSimon Marchi19-27/+217
Building with mingw currently fails: CXX unittests/mkdir-recursive-selftests.o /home/emaisin/src/binutils-gdb/gdb/unittests/mkdir-recursive-selftests.c: In function ‘void selftests::mkdir_recursive::test()’: /home/emaisin/src/binutils-gdb/gdb/unittests/mkdir-recursive-selftests.c:49:20: error: ‘mkdtemp’ was not declared in this scope if (mkdtemp (base) == NULL) ^ Commit e418a61a67a ("Move mkdir_recursive to common/filestuff.c") moved this code, but also removed the HAVE_MKDTEMP guard which prevented the mkdtemp call to be compiled on mingw. We can either put back the HAVE_MKDTEMP ifdef, or import the gnulib mkdtemp module, which provides the function for mingw. Since the mkdir_recursive is susceptible to be used on mingw at some point, I think it would be nice to have it tested on mingw, so I did the latter. Once built, I tested it on Windows (copied the resulting gdb.exe on a Windows machine, ran it, and ran "maint selftest mkdir_recursive"). It failed, because the temporary directory is hardcoded to "/tmp/...". I therefore added and used a new get_standard_temp_dir function, which returns an appropriate temporary directory for the host platform. gdb/ChangeLog: * common/pathstuff.c (get_standard_temp_dir): New. * common/pathstuff.h (get_standard_temp_dir): New. * config.in: Re-generate. * configure: Re-generate. * configure.ac: Don't check for mkdtemp. * gnulib/aclocal-m4-deps.mk: Re-generate. * gnulib/aclocal.m4: Re-generate. * gnulib/config.in: Re-generate. * gnulib/configure: Re-generate. * gnulib/import/Makefile.am: Re-generate. * gnulib/import/Makefile.in: Re-generate. * gnulib/import/m4/gnulib-cache.m4: Re-generate. * gnulib/import/m4/gnulib-comp.m4: Re-generate. * gnulib/import/m4/mkdtemp.m4: New file. * gnulib/import/mkdtemp.c: New file. * gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add mkdtemp module. * unittests/mkdir-recursive-selftests.c (test): Use get_standard_temp_dir. (_initialize_mkdir_recursive_selftests): Remove HAVE_MKDTEMP ifdef. * compile/compile.c (get_compile_file_tempdir): Likewise.
2018-11-01Fix ld action in run_dump_testThomas Preud'homme7-17/+53
run_dump_test proposes an ld action but when trying to make use of it in a gas test it gave me some Tcl error. It turns out that it references the check_shared_lib_support procedure and ld_elf_shared_opt variable both only available in ld-lib.exp. I've thus moved the procedure in binutils-common.exp and defined the variable needed in the various default.exp of testsuite that seem to be using run_dump_test. Since check_shared_lib_support itself references the ld variable not defined in binutils-common I've defined it from LD in run_dump_test and fixed LD and LDFLAGS to be defined as expected by run_dump_test in the various default.exp of testsuite using run_dump_test. 2018-11-01 Thomas Preud'homme <thomas.preudhomme@linaro.org> binutils/ * testsuite/config/default.exp: Define LD, LDFLAGS and ld_elf_shared_opt. * testsuite/lib/binutils-common.exp (check_shared_lib_support): Moved from ld-lib.exp. (run_dump_test): Set ld to $LD. gas/ * testsuite/config/default.exp: Define LD, LDFLAGS and ld_elf_shared_opt. ld/ * testsuite/lib/ld-lib.exp (check_shared_lib_support): Moved to binutils-common.exp.
2018-11-01Reading signal handler frame in AIXSangamesh Mallayya5-1/+210
In AIX if gdb is debugging an application which has a signal handler and reaches the signal handler frame, then we need to read the back chain address from sigcontext saved on the stack, similarly the LR. As backchain at an offset 0 will be 0, because we will have a sigconext saved after the minimum stack size. So the correct backchain will be at an offset after minimum stack and the LR at an offset 8 will be of the signal millicode address. If the back chain pointer is NULL and the LR field is in the kernel segment(ex. 0x00004a14) then we can probably assume we are in a signal handler. sample output (gdb) bt 0 sig_handle_aix (signo=11) at aix-sighandle.c:7 1 0x0000000000004a94 in ?? () (gdb) expected output (gdb) bt 0 sig_handle_aix (signo=11) at aix-sighandle.c:7 1 <signal handler called> 2 0x0000000100000748 in foo () at aix-sighandle.c:14 3 0x000000010000079c in main () at aix-sighandle.c:19 gdb/ChangeLog: 2018-11-01 Sangamesh Mallayya <sangamesh.swamy@in.ibm.com> * rs6000-aix-tdep.c: Include "trad-frame.h" and "frame-unwind.h". (SIG_FRAME_LR_OFFSET64): New define. (SIG_FRAME_FP_OFFSET64): New define. (aix_sighandle_frame_cache): New Function. (aix_sighandle_frame_this_id): New Function. (aix_sighandle_frame_prev_register): New Function. (aix_sighandle_frame_sniffer): New Function. (aix_sighandle_frame_unwind): New global variable. (rs6000_aix_init_osabi): Install new frame unwinder. gdb/testsuite/ChangeLog: 2018-11-01 Sangamesh Mallayya <sangamesh.swamy@in.ibm.com> * gdb.arch/aix-sighandle.c: New file. * gdb.arch/aix-sighandle.exp: New file.
2018-11-01Automatic date update in version.inGDB Administrator1-1/+1
2018-10-31Fix PR gdb/23835: Don't redefine _FORTIFY_SOURCE if it's already definedSergio Durigan Junior2-2/+9
Gentoo has a local GCC patch which always defines _FORTIFY_SOURCE=2. This causes a build problem when building GDB there, because "common/common-defs.h" also defines _FORTIFY_SOURCE=2: CXX gdb.o In file included from ../../gdb/defs.h:28:0, from ../../gdb/gdb.c:19: ../../gdb/common/common-defs.h:71:0: error: "_FORTIFY_SOURCE" redefined [-Werror] #define _FORTIFY_SOURCE 2 <built-in>: note: this is the location of the previous definition cc1plus: all warnings being treated as errors make[2]: *** [Makefile:1619: gdb.o] Error 1 Even though it is questionable whether Gentoo's approach is the correct one: https://jira.mongodb.org/browse/SERVER-29982 https://bugs.gentoo.org/621036 it is still possible for GDB to be a bit more robust here and make sure it just defines _FORTIFY_SOURCE if it hasn't been defined already. This patch does that. Tested by rebuilding and making sure the macro was defined. gdb/ChangeLog: 2018-10-31 Sergio Durigan Junior <sergiodj@redhat.com> PR gdb/23835 * common/common-defs.h: Don't redefine _FORTIFY_SOURCE if it's already defined.
2018-10-31gdb/riscv: Fix failures on rv64 in gdb.arch/riscv-reg-aliases.exp testAndrew Burgess2-66/+121
The gdb.arch/riscv-reg-aliases.exp test didn't take into account that on RV64 (and RV128) the floating point registers are represented as a union. This patch updates the test to handle this. Tested against RV32 and RV64. gdb/testsuite/ChangeLog: * gdb.arch/riscv-reg-aliases.exp: Rewrite to take account of float registers being unions.
2018-10-31[gdb/testsuite] Factor out lib/valgrind.expTom de Vries5-204/+125
Factor out common code related to vgdb setup and cleanup in valgrind-bt.exp, valgrind-disp-step.exp and gdb.base/valgrind-infcall.exp. Tested on x86_64-linux with and without --target_board=native-gdbserver. 2018-10-31 Tom de Vries <tdevries@suse.de> * lib/valgrind.exp: New file. (vgdb_start, vgdb_stop): New procs, factored out of ... * gdb.base/valgrind-bt.exp: ... here, ... * gdb.base/valgrind-disp-step.exp: ... here and ... * gdb.base/valgrind-infcall.exp: ... here.
generated by cgit v1.1 at 2024-12-03 10:36:45 +0000