aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-09-14gas: improve architecture mismatch diagnostics in sparcJose E. Marchesi2-1/+6
Merely dumping the mnemonic name in "architecture mismatch" errors may not provide enough information to determine what went wrong, as the same mnemonic can be used for different variants of an instruction pertaining to different architecture levels. This little patch makes the assembler to include the instruction arguments in the error message. gas/ChangeLog: 2016-09-14 Jose E. Marchesi <jose.marchesi@oracle.com> * config/tc-sparc.c (sparc_ip): Print the instruction arguments in "architecture mismatch" error messages.
2016-09-14gas: detect DCTI couples in sparcJose E. Marchesi11-18/+133
Before SPARC V9 the effect of having a delayed branch instruction in the delay slot of a conditional delayed branch was undefined. In SPARC V9 DCTI couples are well defined. However, starting with the UltraSPARC Architecture 2005, DCTI couples (of all kind) are deprecated and should not be used, as they may be slow or behave differently to what the programmer expects. This patch adds a new command line option --dcti-couples-detect to `as', disabled by default, that makes the assembler to warn the user if an unpredictable DCTI couple is found. Tests and documentation are included. gas/ChangeLog: 2016-09-14 Jose E. Marchesi <jose.marchesi@oracle.com> * config/tc-sparc.c (md_assemble): Detect and warning on unpredictable DCTI couples in certain arches. (dcti_couples_detect): New global. (md_longopts): Add command line option -dcti-couples-detect. (md_show_usage): Document -dcti-couples-detect. (md_parse_option): Handle OPTION_DCTI_COUPLES_DETECT. * testsuite/gas/sparc/sparc.exp (gas_64_check): Run dcti-couples-v8, dcti-couples-v9 and dcti-couples-v9c tests. * testsuite/gas/sparc/dcti-couples.s: New file. * testsuite/gas/sparc/dcti-couples-v9c.d: Likewise. * testsuite/gas/sparc/dcti-couples-v8.d: Likewise. * testsuite/gas/sparc/dcti-couples-v9.d: Likewise. * testsuite/gas/sparc/dcti-couples-v9c.l: Likewise. * testsuite/gas/sparc/dcti-couples-v8.l: Likewise. * doc/as.texinfo (Overview): Document --dcti-couples-detect. * doc/c-sparc.texi (Sparc-Opts): Likewise.
2016-09-14Prevent segfault in GDB when searching for architecture matches.Bhushan Attarde2-0/+9
* format.c (struct bfd_preserve): New "build_id" field. (bfd_preserve_save): Save "build_id". (bfd_preserve_restore): Restore "build_id".
2016-09-14[ARC] Fix parsing dtpoff relocation expression.Claudiu Zissulescu10-1/+90
The assembler accepts dtpoff complex relocation expression like identifier@dtpoff + const. However, it doesn't accept an expression such as identifier@dtpoff@base + const. This patch solves this issue, and adds a number of tests. ld/ 2016-09-14 Claudiu Zissulescu <claziss@synopsys.com> * testsuite/ld-arc/tls-dtpoff.dd: New file. * testsuite/ld-arc/tls-dtpoff.rd: Likewise. * testsuite/ld-arc/tls-dtpoff.s: Likewise. * testsuite/ld-arc/tls-relocs.ld: Likewise. * testsuite/ld-arc/arc.exp: Add new tdpoff test. gas/ 2016-09-14 Claudiu Zissulescu <claziss@synopsys.com> * testsuite/gas/arc/tls-relocs2.d: New file. * testsuite/gas/arc/tls-relocs2.s: Likewise. * config/tc-arc.c (tokenize_arguments): Accept offsets when base is used.
2016-09-14Stop the ARC disassembler from seg-faulting if initialised without a BFD ↵Anton Kolesov2-3/+12
present. * arc-dis.c (arc_get_disassembler): Accept a null bfd gracefully.
2016-09-14Add support for disabling automatic generation of .eh_frame_hdr sections in ↵Nick Clifton5-11/+38
ELF based linkers. PR ld/20537 * emultempl/elf32.em: More OPTION_xxx values into an enum. Add OPTION_NO_EH_FRAME_HDR. (_add_options): Add support for --no-eh-frame-hdr. * ld.texinfo: Document new option. * lexsup.c (elf_shlib_list_options): List new option. * NEWS: Mention the new option.
2016-09-14Automatic date update in version.inGDB Administrator1-1/+1
2016-09-13Fix for gdb.server/non-existing-program.exp test caseCarl E. Love2-2/+7
The last commit was supposed to have the reference to ptrace () removed. The patch didn't get updated correctly before the commit. This commit fixes the comment as requested gdbserver/ChangeLog 2016-09-06 Carl Love <cel@us.ibm.com> * server.c (start_inferior): Fixed comment, requested comment change didn't get updated correctly. Removed reference to ptrace () call as it is only true on Linux systems.
2016-09-13Fix for gdb.server/non-existing-program.exp test caseCarl E. Love2-2/+12
The test checks to make sure GDB exits cleanly if there is no valid target binary. Currently, ppc and S390 fail on this test. The function target_post_create_inferior () calls linux_post_create_inferior () which calls the architecture specific functions s390_arch_setup () and ppc_arch_setup () which make ptrace calls to access the architecture specific registers. These ptrace calls fail because the process does not exist causing GDB to exit on error. This patch checks to see if the initial ptrace (PTRACE_TRACEME, ...) call returned a status of TARGET_WAITKIND_EXITED indicating the target has already exited. If the target has exited, then the target_post_create_inferior () is not called since there is no inferior to be setup. The test to see if the initial ptrace call succeeded is done after the ptrace (PTRACE_TRACEME, ...) call and the wait for the inferior process to stop, assuming it exists, has occurred. The patch has been tested on X86 64-bit, ppc64 and s390. If fixes the test failures on ppc64 and s390. The test does not fail on X86 64-bit. The patch does not introduce any additional regression failures on any of these three platforms. gdbserver/ChangeLog 2016-09-06 Carl Love <cel@us.ibm.com> * server.c (start_inferior): Do not call function target_post_create_inferior () if the inferior process has already exited.
2016-09-13Automatic date update in version.inGDB Administrator1-1/+1
2016-09-12S/390: Add alternate processor names.Andreas Krebbel6-38/+91
This patch adds alternate CPU names which adhere to the number of the architecture document. So instead of having z196, zEC12, and z13 you can use arch9, arch10, and arch11. The old cpu names stay valid and should primarily be used. The alternate names are supposed to improve compatibility with the IBM XL compiler toolchain which uses the arch numbering. opcodes/ChangeLog: 2016-09-12 Andreas Krebbel <krebbel@linux.vnet.ibm.com> * s390-mkopc.c (main): Support alternate arch strings. gas/ChangeLog: 2016-09-12 Andreas Krebbel <krebbel@linux.vnet.ibm.com> * config/tc-s390.c (s390_parse_cpu): Support alternate arch strings. * doc/as.texinfo: Document new arch strings. * doc/c-s390.texi: Likewise.
2016-09-12S/390: Fix facility bit default.Andreas Krebbel2-1/+8
gas/ChangeLog: 2016-09-12 Andreas Krebbel <krebbel@linux.vnet.ibm.com> * config/tc-s390.c: Set all facitily bits by default
2016-09-12S/390: Fix kmctr instruction type.Patrick Steuer4-2/+10
opcodes/ChangeLog: 2016-09-12 Patrick Steuer <steuer@linux.vnet.ibm.com> * s390-opc.txt: Fix kmctr instruction type. gas/ChangeLog: 2016-09-12 Patrick Steuer <steuer@linux.vnet.ibm.com> * testsuite/gas/s390/zarch-z196.d: Adjust testcase.
2016-09-12Fix false FAIL on gdb.base/stap-probe.exp, due to ICF optimizationSergio Durigan Junior2-1/+13
GCC 6's ICF optimization pass is making the declaration of 'm1' and 'm2', on gdb.base/stap-probe.c, to be unified. However, this leads to only one instance of the probe 'two' being created, which causes a failure on the testsuite (which expects a multi-location breakpoint to be inserted on the probe). This patch fixes this failure by declaring a dummy variable on 'm1', and using it as an argument to m1's version of probe 'two'. Since we do not care about the contents of the functions nor about the arguments of each probe 'two', this is OK. gdb/testsuite/ChangeLog: 2016-09-11 Sergio Durigan Junior <sergiodj@redhat.com> Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.base/stap-probe.c (m1): New variable 'dummy', necessary to make m1's definition to be different from m2's. Use 'dummy' as an argument for probe 'two'.
2016-09-12Automatic date update in version.inGDB Administrator1-1/+1
2016-09-11Automatic date update in version.inGDB Administrator1-1/+1
2016-09-10Use target_sim_options for sim target.Jon Beniston2-1/+7
2016-09-10 Jon Beniston <jon@beniston.com> * lib/mi-support.exp (mi_gdb_target_load): Use target_sim_options for sim target.
2016-09-10Automatic date update in version.inGDB Administrator1-1/+1
2016-09-09Pass HWCAP to ifunc resolverAndreas Arnez6-4/+46
On various GNU Elf architectures, including AArch64, ARM, s390/s390x, ppc32/64, and sparc32/64, the dynamic loader passes HWCAP as a parameter to each ifunc resolver. Currently there is an open glibc Bugzilla that requests this to be generalized to all architectures: https://sourceware.org/bugzilla/show_bug.cgi?id=19766 And various ifunc resolvers already rely on receiving HWCAP. Currently GDB always calls an ifunc resolver without any arguments; thus the resolver may receive garbage, and based on that, the resolver may decide to return a function that is not suited for the given platform. This patch always passes HWCAP to ifunc resolvers, even on systems where the dynamic loader currently behaves otherwise. The rationale is that (1) the dynamic loader may get adjusted on those systems as well in the future; (2) passing an unused argument should not cause a problem with existing resolvers; and (3) the logic is much simpler without such a distinction. gdb/ChangeLog: * elfread.c (auxv.h): New include. (elf_gnu_ifunc_resolve_addr): Pass HWCAP to ifunc resolver. gdb/testsuite/ChangeLog: * gdb.base/gnu-ifunc-lib.c (resolver_hwcap): New external variable declaration. (gnu_ifunc): Add parameter hwcap. Store it in resolver_hwcap. * gdb.base/gnu-ifunc.c (resolver_hwcap): New global variable. * gdb.base/gnu-ifunc.exp: Add test to verify that the resolver received HWCAP as its argument.
2016-09-09Automatic date update in version.inGDB Administrator1-1/+1
2016-09-08Remove some unneeded casts from remote.cTom Tromey2-4/+9
I happened to notice a few unneeded casts in remote.c. In some cases these are no-ops, and in others these cast away const, but in a context where this is not needed. I'm checking this in under the obvious rule. Tested by rebuilding on x86-64 Fedora 24. 2016-09-08 Tom Tromey <tom@tromey.com> * remote.c (remote_notif_stop_ack, remote_wait_as) (show_remote_cmd): Remove unneeded casts.
2016-09-08Allow PROCESSOR_IAMCU for Intel MCUH.J. Lu2-1/+6
* config/tc-i386.c (i386_target_format): Allow PROCESSOR_IAMCU for Intel MCU.
2016-09-08Automatic date update in version.inGDB Administrator1-1/+1
2016-09-07X86: Allow additional ISAs for IAMCU in assemblerH.J. Lu14-39/+55
Originally only Pentium integer instructions are allowed for IAMCU. This patch removes such a restriction. For example, 387 and SSE2 instructions can be enabled by passing "-march=iamcu+sse2+387" to assembler. gas/ * config/tc-i386.c (valid_iamcu_cpu_flags): Removed. (set_cpu_arch): Updated. (md_parse_option): Likewise. * testsuite/gas/i386/i386.exp: Run iamcu-4 and iamcu-5. Remove iamcu-inval-2 and iamcu-inval-3. * testsuite/gas/i386/iamcu-4.d: New file. * testsuite/gas/i386/iamcu-4.s: Likewise. * testsuite/gas/i386/iamcu-5.d: Likewise. * testsuite/gas/i386/iamcu-5.s: Likewise. * testsuite/gas/i386/iamcu-inval-2.l: Removed. * testsuite/gas/i386/iamcu-inval-2.s: Likewise. * testsuite/gas/i386/iamcu-inval-3.l: Likewise. * testsuite/gas/i386/iamcu-inval-3.s: Likewise. opcodes/ * i386-gen.c (cpu_flag_init): Remove CPU_IAMCU_COMPAT_FLAGS. * i386-init.h: Regenerated.
2016-09-07[arm] Automatically enable CRC instructions on supported ARMv8-A CPUs.Richard Earnshaw4-9/+20
2016-09-07 Richard Earnshaw <rearnsha@arm.com> * opcode/arm.h (ARM_ARCH_V8A_CRC): New architecture. 2016-09-07 Richard Earnshaw <rearnsha@arm.com> * config/tc-arm.c ((arm_cpus): Use ARM_ARCH_V8A_CRC for all ARMv8-A CPUs except xgene1.
2016-09-07Automatic date update in version.inGDB Administrator1-1/+1
2016-09-06new-ui command: gdb internal errors if input is already pendingPedro Alves6-3/+194
I noticed that if input is already pending on the new-ui TTY, gdb internal-errors. E.g., create /dev/pts/2, and type anything there (even just <return> is sufficient). Now start GDB creating a new UI on that TTY, while at the same time, running a synchronous execution command. Something like: $ gdb program -ex "new-ui console /dev/pts/2" -ex "start" Back on /dev/pts/2, we get: (gdb) .../src/gdb/event-top.c:360: internal-error: double prompt A problem internal to GDB has been detected, further debugging may prove unreliable. While the main UI was waiting for "start" to finish, gdb kepts pumping events, including the input fd of the extra console. The problem is that stdin_event_handler doesn't restore the current UI back to what it was, assuming that it's only ever called from the top level event loop. However, in this case, it's being called from the nested event loop from within maybe_wait_sync_command_done. When finally the "start" command is done, we reach the code that prints the prompt in the main UI, just before starting the main event loop. Since now the current UI is pointing at the extra console (by mistake), we find ourselves printing a double prompt on the extra console. This is caught by the assertion that fails, as shown above. Since other event handlers also don't restore the UI (e.g., signal event handlers), I think it's better if whatever is pumping events to take care to restore the UI, if it cares. That's what this patch does. New test included. gdb/ChangeLog: 2016-09-06 Pedro Alves <palves@redhat.com> * top.c (wait_sync_command_done): Don't assume current_ui doesn't change across events. Restore the current UI before returning. (gdb_readline_wrapper): Restore the current UI before returning. gdb/testsuite/ChangeLog: 2016-09-06 Pedro Alves <palves@redhat.com> * gdb.base/new-ui-pending-input.c: New file. * gdb.base/new-ui-pending-input.exp: New file. * gdb.exp (clear_gdb_spawn_id): New procedure. (with_spawn_id): Check whether gdb_spawn_id exists before referencing it. If gdb_spawn_id didn't exist on entry, clear it on exit.
2016-09-06Introduce make_cleanup_restore_current_uiPedro Alves6-8/+27
Just a tidy, no functional changes. gdb/ChangeLog: 2016-09-06 Pedro Alves <palves@redhat.com> * event-top.c (restore_ui_cleanup): Now static. (make_cleanup_restore_current_ui): New function. (switch_thru_all_uis_init): Use it. * infcall.c (call_thread_fsm_should_stop): Use it. * infrun.c (fetch_inferior_event): Use it. * top.c (new_ui_command): Use it. * top.h (restore_ui_cleanup): Delete declaration. (make_cleanup_restore_current_ui): New declaration.
2016-09-06Resolve size relocation with copy relocationH.J. Lu6-1/+39
We can resolve size relocation against symbol which needs copy relocation when building executable. bfd/ PR ld/20550 * elf64-x86-64.c (elf_x86_64_relocate_section): Resolve size relocation with copy relocation when building executable. ld/ PR ld/20550 * testsuite/ld-x86-64/pr20550a.s: New file. * testsuite/ld-x86-64/pr20550b.s: Likewise. * testsuite/ld-x86-64/x86-64.exp (x86_64tests): Add tests for PR ld/20550.
2016-09-06Do not pass host compiler sanitization flags on to linker testsuite.Nick Clifton3-4/+21
* Makefile.am (CFLAGS_FOR_TARGET): Define as a copy of CFLAGS but without any sanitization options. (CXXFLAGS_FOR_TARGET): Define as a copy of CXXFLAGS but without any sanitization options. (check-DEJAGNU): Pass CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET as CFLAGS and CXXFLAGS respectively.
2016-09-06Support 128-bit IEEE floating-point types on Intel and PowerUlrich Weigand8-0/+334
Now that all the prerequisites are in place, this commit finally adds support for handling the __float128 type on Intel and Power, by providing appropriate platform-specific versions of the floatformat_for_type callback. Since at this point we do not yet have any indication in the debug info to distinguish different floating-point formats of the same length, we simply use the type name as hint. Types named "__float128" get the IEEE format. In addition to handling "__float128" itself, we also recognize "_Float128" and (on Power) "_Float64x", as well as the complex versions of those. (As pointed out by Joseph Myers, starting with GCC 7, __float128 is just a typedef for _Float128 -- but it's good to handle this anyway.) A new test case does some simple verification that the format is decoded correctly, using both __float128 and "long double" to make sure using both in the same file still works. Another new test verifies handling of the _FloatN and _FloatNx types supported by GCC 7, as well as the complex versions of those types. Note that this still only supports basic format decoding and encoding. We do not yet support the GNU extension 'g' suffix for __float128 constants. In addition, since all *arithmetic* on floating-point values is still performed in native host "long double" arithmetic, if that format is not able to encode all target __float128 values, we may get incorrect results. (To fix this would require implementing fully synthetic target floating- point arithmetic along the lines of GCC's real.c, presumably using MPFR.) gdb/ChangeLog: * i386-tdep.c (i386_floatformat_for_type): New function. (i386_gdbarch_init): Install it. * ppc-linux-tdep.c (ppc_floatformat_for_type): New function. (ppc_linux_init_abi): Install it. gdb/testsuite/ChangeLog: * gdb.base/float128.c: New file. * gdb.base/float128.exp: Likewise. * gdb.base/floatn.c: Likewise. * gdb.base/floatn.exp: Likewise. Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
2016-09-06Add gdbarch callback to provide formats for debug info float typesUlrich Weigand10-68/+141
At this point, all TYPE_CODE_FLT types carry their floating-point format, except for those creating from reading DWARF or stabs debug info. Those will be addressed by this commit. The main issue here is that we actually have to determine which floating- point format to use. Currently, we only have the type length as input to this decision. In the future, we may hopefully get --at least in DWARF-- additional information to help disambiguate multiple different formats of the same length. For now, we can still look at the type name as a hint. This decision logic is encapsulated in a gdbarch callback to allow platform-specific overrides. The default implementation use the same logic (compare type length against the various gdbarch_..._bit sizes) that is currently implemented in floatformat_from_length. With this commit, all platforms still use the default logic, so there should be no actual change in behavior. A follow-on commit will add support for __float128 on Intel and Power. Once dwarf2read.c and stabsread.c make use of the new callback to determine floating-point formats, we're now sure every TYPE_CODE_FLT type will always carry its format. The commit therefore adds asserts to verify_floatformat to ensure new code will continue to always provide formats, and removes the code in floatformat_from_type that used to handle types with a NULL TYPE_FLOATFORMAT. gdb/ChangeLog: * gdbarch.sh (floatformat_for_type): New gdbarch callback. * gdbarch.h, gdbarch.c: Re-generate. * arch-utils.h (default_floatformat_for_type): New prototype. * arch-utils.c (default_floatformat_for_type): New function. * doublest.c (floatformat_from_length): Remove. (floatformat_from_type): Assume TYPE_FLOATFORMAT is non-NULL. * gdbtypes.c (verify_floatformat): Require non-NULL format. * dwarf2read.c (dwarf2_init_float_type): New function. (read_base_type): Use it. * stabsread.c (dbx_init_float_type): New function. (read_sun_floating_type): Use it. (read_range_type): Likewise. Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
2016-09-06Add missing format for built-in floating-point typesUlrich Weigand10-26/+49
Many callers of init_float_type and arch_float_type still pass a NULL floatformat. This commit changes those callers where the floatformat that is supposed to be use is obvious. There are two categories where this is the case: - A number of built-in types are intended to match the platform ABI floating-point types (i.e. types that use gdbarch_float_bit etc.). Those places should use the platform ABI floating-point formats defined via gdbarch_float_format etc. - A number of language built-in types should simply use IEEE floating- point formats, since the language actually defines that this is the format that must be used to implement floating-point types for this language. (This affects Java, Go, and Rust.) The same applies for to the predefined "RS/6000" stabs floating-point built-in types. gdb/ChangeLog: * ada-lang.c (ada_language_arch_info): Use gdbarch-provided platform ABI floating-point formats for built-in types. * d-lang.c (build_d_types): Likewise. * f-lang.c (build_fortran_types): Likewise. * m2-lang.c (build_m2_types): Likewise. * mdebugread.c (basic_type): Likewise. * go-lang.c (build_go_types): Use IEEE floating-point formats for language built-in types as mandanted by the language. * jv-lang.c (build_java_types): Likewise. * rust-lang.c (rust_language_arch_info): Likewise. * stabsread.c (rs6000_builtin_type): Likewise. Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
2016-09-06Remove TYPE_NOSIGN "char" hackUlrich Weigand4-7/+13
init_type (and arch_integer_type) currently use a special hack to set the TYPE_NOSIGN flag if the type name is exactly "char". This commit moves the hack up to the callers of those routines. The special case currently can hit only for types created from dwarf2read, but read_base_type actually implements the "char" check itself, so it is redundant to do it in init_type as well. (Note that stabsread.c and the other type readers always pass NULL as name to init_type, so the special case can never hit for those.) A few other cases create pre-definded types with a hard-coded name of "char"; the commit simply moves setting the TYPE_NOSIGN flag to those places. No functional change intended. gdb/ChangeLog: * gdbtypes.c (init_type): Remove "char" special case. (arch_integer_type): Likewise. (gdbtypes_post_init): Set TYPE_NOSIGN for "char" type. (objfile_type): Likewise. * mdebugread.c (basic_type): Likewise. * stabsread.c (rs6000_builtin_type): Likewise. Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
2016-09-06Remove obsolete TYPE_FLAG_... valuesUlrich Weigand8-84/+58
Now that init_type no longer takes a FLAGS argument, there is no user of the TYPE_FLAGS_... enum values left. This commit removes them (and all references to them in comments as well). This is mostly a no-op, except for a change to the Python type printer, which attempted to use them before. (As best as I can tell, this wasn't really needed anyway, since it was only used to pretty-print type *instance* flags, which only use the instance flags.) gdb/ChangeLog: * gdbtypes.h (enum type_flag_value): Remove. Remove references to TYPE_FLAG_... in comments throughout. * gdbtypes.c (recursive_dump_type): Do not print TYPE_FLAG_... flags, print the corresponding TYPE_... access macro names. Remove references to TYPE_FLAG_... in comments throughout. * infcall.c: Remove references to TYPE_FLAG_... in comments. * valprint.c: Likewise. * gdb-gdb.py (class TypeFlag): No longer consider TYPE_FLAG_... values, only TYPE_INSTANCE_FLAG_... values. (class TypeFlagsPrinter): Likewise. gdb/testsuite/ChangeLog: * gdb.cp/hang.exp: Remove reference to TYPE_FLAG_STUB in comment. Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
2016-09-06Unify init_type and arch_type interface and helpersUlrich Weigand6-317/+388
This adds a number of helper routines for creating objfile-owned types; these correspond 1:1 to the already existing helper routines for creating gdbarch-owned types, and are intended to be used instead of init_type. A shared fragment of init_float_type and arch_float_type is extracted into a separate subroutine verify_subroutine. The commit also brings the interface of init_type in line with the one for arch_type. In particular, this means removing the FLAGS argument; callers now set the required flags directly. (Since most callers use the new helper routines, very few callers actually need to set any additional flags directly any more.) Note that this means all the TYPE_FLAGS_... defined are no longer needed anywhere; they will be removed by a follow-on commit. All users of init_type are changed to use on of the new helpers where possible. No functional change intended. gdb/ChangeLog: * gdbtypes.h (init_type): Remove FLAGS argument. Move OBJFILE argument to first position. (init_integer_type): New prototype. (init_character_type): Likewise. (init_boolean_type): Likewise. (init_float_type): Likewise. (init_decfloat_type): Likewise. (init_complex_type): Likewise. (init_pointer_type): Likewise. * gdbtypes.c (verify_floatflormat): New function. (init_type): Remove FLAGS argument and processing. Move OBJFILE argument to first position. (init_integer_type): New function. (init_character_type): Likewise. (init_boolean_type): Likewise. (init_float_type): Likewise. (init_decfloat_type): Likewise. (init_complex_type): Likewise. (init_pointer_type): Likewise. (arch_float_type): Use verify_floatflormat. (objfile_type): Use init_..._type helpers instead of calling init_type directly. * dwarf2read.c (fixup_go_packaging): Update to changed init_type prototype. (read_namespace_type): Likewise. (read_module_type): Likewise. (read_typedef): Likewise. (read_unspecified_type): Likewise. (build_error_marker_type): Likewise. (read_base_type): Use init_..._type helpers. * mdebugread.c (basic_type): Use init_..._type helpers. (parse_type): Update to changed init_type prototype. (cross_ref): Likewise. * stabsread.c (rs6000_builtin_type): Use init_..._type helpers. (read_sun_builtin_type): Likewise. (read_sun_floating_type): Likewise. (read_range_type): Likewise. Also update to changed init_type prototype. Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
2016-09-06Add some missing arch_..._type helpersUlrich Weigand7-30/+56
gdbtypes provides a number of helper routines that can be called instead of using arch_type directly to create a type of a particular kind. This patch adds two additional such routines that have been missing so far, to allow creation of TYPE_CODE_DECFLOAT and TYPE_CODE_POINTER types. The patch also changes a number of places to use the new helper routines instead of calling arch_type directly. No functional change intended. gdb/ChangeLog: * gdbtypes.h (arch_decfloat_type): New prototype. (arch_pointer_type): Likewise. * gdbtypes.c (arch_decfloat_type): New function. (arch_pointer_type): Likewise. (gdbtypes_post_init): Use arch_decfloat_type. * avr-tdep.c (avr_gdbarch_init): Use arch_pointer_type. * ft32-tdep.c (ft32_gdbarch_init): Likewise. * m32c-tdep.c (make_types): Likewise. * rl78-tdep.c (rl78_gdbarch_init): Likewise. Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
2016-09-06Fix TYPE_SPECIFIC_FIELD for types created via arch_typeUlrich Weigand2-16/+31
A type's TYPE_SPECIFIC_FIELD is supposed to be initialized as appropriate for the type code. This does happen if the type is created via init_type, but not if it created via arch_type. Fixed by extracting the initialization logic into a new set_type_code routine, which is then called from both places. gdb/ChangeLog: * gdbtypes.c (set_type_code): New function. (init_type, arch_type): Use it. Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
2016-09-06Fix typo in ada_language_arch_infoUlrich Weigand2-1/+6
This fixes a bug introduced by a wrong replacement here: https://sourceware.org/ml/gdb-patches/2007-06/msg00196.html The Ada "long_long_float" type is supposed to correspond to the platform ABI long double type, not double. gdb/ChangeLog: * ada-lang.c (ada_language_arch_info): Use gdbarch_long_double_bit instead of gdbarch_double_bit for "long_long_float". Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
2016-09-06Fix a problem in readelf where memcpy could be called with a NULL second ↵Nick Clifton2-3/+11
argument. * readelf.c (request_dump_bynumber): Only call memcpy if dump_sects is not NULL.
2016-09-06Fix PR ld/20545 - relaxation bugs in avr backendSenthil Kumar Selvaraj7-7/+94
Prior to the patch, addends for relocs were being adjusted even if they went beyond an alignment boundary. This is wrong - to preserve alignment constraints, the relaxation logic adds as many padding bytes at the alignment boundary as was deleted, so addends beyond the boundary should not be adjusted. avr-prop-7.s reproduces this scenario. Also, prior to this patch, the relaxation logic assumed that the addr parameter pointed to the middle of the instruction to be deleted, and that addr - count would therefore be the shrinked instruction's address. This is true when actually shrinking instructions. The alignment constraints handling logic also invokes the same logic though, with addr as the starting offset of padding bytes and with count as the number of bytes to be deleted. Calculating the shrinked insn's address as addr - count is obviously wrong in this case - that offset would point to count bytes before the last non-padded byte. avr-prop-8.s reproduces this scenario. To fix scenario 1, the patch adds an additional check to ensure reloc addends aren't adjusted if they cross a shrink boundary. The shrink boundary is either the section size or an alignment boundary. Addends pointing at an alignment boundary don't need to be adjusted, as padding would occur and keep the boundary the same. Addends pointing at section size need to be adjusted though, as no padding occurs and the section size itself would get decremented. The patch records whether padding occured (did_pad) and uses that to detect and handle this condition. To fix scenario 2, the patch adds an additional parameter (delete_shrinks_insn) to elf32_avr_relax_delete_bytes to distinguish instruction bytes deletion from padding bytes deletion. It then uses that to correctly set shrinked_insn_address. bfd/ChangeLog: 2016-09-02 Senthil Kumar Selvaraj <senthil_kumar.selvaraj@atmel.com> PR ld/20545 * elf32-avr.c (elf32_avr_relax_delete_bytes): Add parameter delete_shrinks_insn. Modify computation of shrinked_insn_address. Compute shrink_boundary and adjust addend only if addend_within_shrink_boundary. (elf32_avr_relax_section): Modify calls to elf32_avr_relax_delete_bytes to pass extra parameter. ld/ChangeLog: 2016-09-02 Senthil Kumar Selvaraj <senthil_kumar.selvaraj@atmel.com> PR ld/20545 * testsuite/ld-avr/avr-prop-7.d: New test. * testsuite/ld-avr/avr-prop-7.s: New test. * testsuite/ld-avr/avr-prop-8.d: New test. * testsuite/ld-avr/avr-prop-8.s: New test.
2016-09-06Automatic date update in version.inGDB Administrator1-1/+1
2016-09-05gdb/: Require a C++ compilerPedro Alves13-190/+51
This removes all support for building gdb & gdbserver with a C compiler from gdb & gdbserver's build machinery. gdb/ChangeLog: 2016-09-05 Pedro Alves <palves@redhat.com> * NEWS: Mention that a C++ compiler is now required. * Makefile.in (COMPILER, COMPILER_CFLAGS): Remove. (COMPILE.pre, CC_LD): Use CXX directly. (INTERNAL_CFLAGS_BASE): Use CXXFLAGS directly. * acinclude.m4: Don't include build-with-cxx.m4. * build-with-cxx.m4: Delete file. * configure.ac: Remove GDB_AC_BUILD_WITH_CXX call. * warning.m4: Assume $enable_build_with_cxx is yes. * configure: Regenerate. gdb/gdbserver/ChangeLog: 2016-09-05 Pedro Alves <palves@redhat.com> * Makefile.in (COMPILER, COMPILER_CFLAGS): Remove. (COMPILE.pre, CC_LD): Use CXX directly. (INTERNAL_CFLAGS_BASE): Use CXXFLAGS directly. * acinclude.m4: Don't include build-with-cxx.m4. * configure.ac: Remove GDB_AC_BUILD_WITH_CXX call. * configure: Regenerate.
2016-09-05Fix PR19927: Avoid unwinder recursion if sniffer uses calls parse_and_evalPedro Alves5-32/+76
This fixes the problem exercised by Kevin's test at: https://sourceware.org/ml/gdb-patches/2016-08/msg00216.html This was originally exposed by the OpenJDK Python-based unwinder. If an unwinder attempts to call parse_and_eval from within its sniffing method, GDB's unwinding machinery enters infinite recursion. However, parse_and_eval is a pretty reasonable thing to call, because Python/Scheme-based unwinders will often need to read globals out of inferior memory. The recursion happens because: - get_current_frame() is called soon after the target stops. - current_frame is NULL, and so we unwind it from the sentinel frame (which is special and has level == -1). - We reach get_prev_frame_if_no_cycle, which does cycle detection based on frame id, and thus tries to compute the frame id of the new frame. - Frame id computation requires an unwinder, so we go through all unwinder sniffers trying to see if one accepts the new frame (the current frame). - the unwinder's sniffer calls parse_and_eval(). - parse_and_eval depends on the selected frame/block, and if not set yet, the selected frame is set to the current frame. - get_current_frame () is called again. current_frame is still NULL, so ... - recurse forever. In Kevin's test at: https://sourceware.org/ml/gdb-patches/2016-08/msg00216.html gdb doesn't recurse forever simply because the Python unwinder contains code to detect and stop the recursion itself. However, GDB goes downhill from here, e.g., by showing the sentinel frame as current frame (note the -1): Breakpoint 1, ccc (arg=<unavailable>) at py-recurse-unwind.c:23 23 } (gdb) bt #-1 ccc (arg=<unavailable>) at py-recurse-unwind.c:23 Backtrace stopped: previous frame identical to this frame (corrupt stack?) That "-1" frame level comes from this: if (catch_exceptions (current_uiout, unwind_to_current_frame, sentinel_frame, RETURN_MASK_ERROR) != 0) { /* Oops! Fake a current frame? Is this useful? It has a PC of zero, for instance. */ current_frame = sentinel_frame; } which is bogus. It's never correct to set the current frame to the sentinel frame. The only reason this has survived so long is that getting here normally indicates something wrong has already happened before and we fix that. And this case is no exception -- it doesn't really matter how precisely we managed to get to that bogus code (it has to do with the the stash), because anything after recursion happens is going to be invalid. So the fix is to avoid the recursion in the first place. Observations: #1 - The recursion happens because we try to do cycle detection from within get_prev_frame_if_no_cycle. That requires computing the frame id of the frame being unwound, and that itself requires calling into the unwinders. #2 - But, the first time we're unwinding from the sentinel frame, when we reach get_prev_frame_if_no_cycle, there's no frame chain at all yet: - current_frame is NULL. - the frame stash is empty. Thus, there's really no need to do cycle detection the first time we reach get_prev_frame_if_no_cycle, when building the current frame. So we can break the recursion by making get_current_frame call a simplified version of get_prev_frame_if_no_cycle that results in setting the current_frame global _before_ computing the current frame's id. But, we can go a little bit further. As there's really no reason anymore to compute the current frame's frame id immediately, we can defer computing it to when some caller of get_current_frame might need it. This was actually how the frame id was computed for all frames before the stash-based cycle detection was added. So in a way, this patch reintroduces the lazy frame id computation, but unlike before, only for the case of the current frame, which turns out to be special. This lazyness, however, requires adjusting gdb.python/py-unwind-maint.exp, because that assumes unwinders are immediately called as side effect of some commands. I didn't see a need to preserve the behavior expected by that test (all it would take is call get_frame_id inside get_current_frame), so I adjusted the test. gdb/ChangeLog: 2016-09-05 Pedro Alves <palves@redhat.com> PR backtrace/19927 * frame.c (get_frame_id): Compute the frame id if not computed yet. (unwind_to_current_frame): Delete. (get_current_frame): Use get_prev_frame_always_1 to get the current frame and assert that that always succeeds. (get_prev_frame_if_no_cycle): Skip cycle detection if returning the current frame. gdb/testsuite/ChangeLog: 2016-09-05 Pedro Alves <palves@redhat.com> PR backtrace/19927 * gdb.python/py-unwind-maint.exp: Adjust tests to not expect that unwinders are immediately called as side effect of "source" or "disable unwinder" commands. * gdb.python/py-recurse-unwind.exp: Remove setup_kfail calls.
2016-09-05Automatic date update in version.inGDB Administrator1-1/+1
2016-09-04Automatic date update in version.inGDB Administrator1-1/+1
2016-09-03Removed redundant line remote-utils.cAkash Trehan2-1/+6
2016-09-02 Akash Trehan <akash.trehan123@gmail.com> gdb/gdbserver/ChangeLog: PR gdb/19495 * remote-utils.c (relocate_instruction): Remove redundant strcpy() call writing data to own_buf.
2016-09-03Automatic date update in version.inGDB Administrator1-1/+1
2016-09-02Handle ARM-specific --target1-abs, --target1-rel and --target2 optionsDoug Kwan12-16/+484
2016-09-02Handle DW_OP_form_tls_addressTom Tromey6-7/+26
Currently gdb supports DW_OP_GNU_push_tls_address, but not DW_OP_form_tls_address. I think it would be better if the toolchain as a whole moved to using the standard opcode, and the prerequisite to this is getting gdb to recognize it. GCC can sometimes emit DW_OP_form_tls_address for emultls targets. As far as I know, nobody has ever tried this with gdb (since it wouldn't work at all). I don't think there's a major drawback to using a single opcode for all targets, because computing the location of a thread-local is already target specific. This is PR gdb/11616. I don't know how to write a test case for this; though it's worth noting that there aren't explicit tests for DW_OP_GNU_push_tls_address either -- and if I change GCC, these paths will be tested to the same extent they are now. 2016-09-02 Tom Tromey <tom@tromey.com> PR gdb/11616: * dwarf2read.c (decode_locdesc): Handle DW_OP_form_tls_address. * dwarf2loc.c (dwarf2_compile_expr_to_ax): Handle DW_OP_form_tls_address. (locexpr_describe_location_piece): Likewise. * dwarf2expr.h (struct dwarf_expr_context_funcs): Update comment. * dwarf2expr.c (execute_stack_op): Handle DW_OP_form_tls_address. (ctx_no_get_tls_address): Mention DW_OP_form_tls_address. * compile/compile-loc2c.c (struct insn_info): Update comment. (compute_stack_depth_worker): Handle DW_OP_form_tls_address.
generated by cgit v1.1 at 2024-08-02 07:19:59 +0000