bfd/
* elf32-ppc.c (ppc_elf_reloc_type_lookup): Decode ppc64 _DS
bfd_reloc values. Map to corresponding D-form relocs.
(is_insn_ds_form, is_insn_qs_form): New functions.
(ppc_elf_relocate_section): Validate insn with DS-form or DQ-form
fields using D-form reloc.
gas/
* config/tc-ppc.c (ppc_setup_opcodes): Fix comment.
(md_assemble): Translate to _DS relocs for ppc32 as well as ppc64.
(tc_gen_reloc): Handle _DS relocs in ppc32 mode.
That was an attempt at handling the targets where sizeof(long double)
is less than 8, but the way it was implement allows the bug that
this testcase verifies to come back without being noticed.
gdb/testsuite/ChangeLog:
* gdb.base/ldbl_e308.exp: Remove "inf" from possible expected
output for "print inp" test.
* ld-elfvsb/main.c (main_visibility_checkcom): Remove address
check for visibility_def if HIDDEN_UNDEF_TEST is defined.
(main_visibility_checkweak): Remove address check for
visibility_func if HIDDEN_UNDEF_TEST is defined.
* gas/i386/rex.s: Add test of REX prefix before fsave (i.e. fwait).
* gas/i386/rex.d: Update.
opcodes/
* i386-dis.c (ckprefix): When bailing out for fwait with prefixes,
set rex_used to rex.
When debugging a program using the Ravenscar profile, the debugger
sometimes tries to send the following packet to the remote after
the inferior exited.
(gdb) c
Continuing.
[...]
Sending packet: $vCont;c:1#13...Ack
Packet received: W00
Sending packet: $Hg1#e0...putpkt: write failed: Broken pipe.
As the inferior exited, the remote has already disconnected, and thus
the operation fails.
The reason why GDB sends the package is because the ravenscar-thread
module tries to updates the list of threads. But this doesn't make
sense, since the program has exited. This patch fixes it.
gdb/ChangeLog:
* ravenscar-thread.c (ravenscar_wait): Only update the list
of threads and inferior_ptid if the inferior is still alive.
We use a list of regular expressions to match a symtab filenames
against the names of the files in the Ada runtime. These regular
expressions do assume that the filename is a basename, however.
So make sure to evaluate these regular expressions against
the symtab's filename.
Without this patch, we run into problems when the Ada runtime was built
using a project file (through gprbuild).
gdb/ChangeLog:
* ada-lang.c (is_known_support_routine): Use lbasename when
matching the symtab's filename against
known_runtime_file_name_patterns.
Given the following variable declaration...
Www : Wide_String := "12345";
... this patch allows the following assignment to work:
(gdb) set variable www := "qwert"
Without this patch, the debugger rejects the assignment because
the size of the array elements are different:
(gdb) set www := "asdfg"
Incompatible types in assignment
(on the lhs, we have an array of 2-bytes elements, and on the rhs,
we have a standard 1-byte string).
gdb/ChangeLog:
* ada-lang.c (ada_same_array_size_p): New function.
(ada_promote_array_of_integrals): New function.
(coerce_for_assign): Add handling of arrays where the elements
are integrals of a smaller size than the size of the target
array element type.
gdb/testsuite/ChangeLog:
* gdb.ada/set_wstr: New testcase.
Assuming the following variable definition:
long double inp = 2.0;
On platforms where "long double" is a double precision IEEE flaoting
point, GDB currently behaves as follow:
(gdb) set variable inp = 1.6e+308l
(gdb) p inp
$2 = inf <<<<---- !!!!
Instead, the value of "inp" should be printed as:
(gdb) p inp
$1 = 1.6e+308
The problem is due to a small error in the comparison of the exponent
versus the maximum value this exponent can take, causing us to think
that the value was too big to fit. But it isn't.
gdb/ChangeLog:
* doublest.c (convert_doublest_to_floatformat): Fix comparison
against maximum exponent value.
gdb/testsuite/ChangeLog:
* gdb.base/ldbl_e308.c, gdb.base/ldbl_e308.exp: New files.
On x86_64-windows with GCC 4.7 (using native SEH info), the debugger
behaves as follow:
(gdb) catch exception unhandled
Catchpoint 1: unhandled Ada exceptions
(gdb) run
Starting program: C:\[...]\b.exe
Catchpoint 1, unhandled CONSTRAINT_ERROR at 0x000000000040cc57 in _GCC_specific_handler ([...]) at ../../../src/libgcc/unwind-seh.c:289
[...]
This is after compiler the following code:
procedure B is
begin
raise Constraint_Error;
end B;
... using the following command:
% gnatmake -g b
When hitting the exception catchpoint, it should have gone up the stack
all the way until finding the frame corresponding to procedure B.
But if stopped short because unwind-seh.c is compiled with debugging
information, and the debugger is also able to locate that source file.
To prevent this from happening, this patch adds unwind-seh.c to the list
of files that should be ignored, regardless of other factors.
gdb/ChangeLog:
* ada-lang.h (ADA_KNOWN_RUNTIME_FILE_NAME_PATTERNS): Add entry for
"unwind-seh.c".
gdb/ChangeLog:
* ada-lang.c (ada_template_to_fixed_record_type_1): Do not
strip typedef layer when computing the fixed type's field type,
only when computing its size.
gdb/testsuite/ChangeLog:
* gdb.ada/unc_arr_ptr_in_var_rec: New testcase.
The following works...
% gdb c:\path to exe\foo.exe
(gdb) start
... unless a file or directory called "c:\path" or "c:\path to" exist.
This is what happens in the latter case:
(gdb) start
[...]
Error creating process C:\path to exe\foo.exe (error 193).
This is because we are calling CreateProcess (et al) without specifying
the lpApplicationName, so Windows determines the name of the executable
using the second argument, which is the entire command line. This
command line is a space-separated list of tokens, so the space in
the path to the executable which potentially creates an ambiguity.
The ambiguity is automatically resolved unless we're in the situation
above.
The solution, as suggested by the MSDN documentation for CreateProcess
is to quote the executable name.
gdb/ChangeLog:
* windows-nat.c (windows_create_inferior) [!__CYGWIN__]:
New local variable args_len.
Quote the name of the executable when computing the command line.
