bfd * elfnn-aarch64.c (elfNN_aarch64_relocate_section): Add a more
helpful warning message to explain why certain AArch64 relocs
might overflow.
ld * testsuite/ld-aarch64/reloc-overflow-bad.d: New test.
* testsuite/ld-aarch64/reloc-overflow-1.s: New source file.
* testsuite/ld-aarch64/reloc-overflow-2.s: New source file.
* testsuite/ld-aarch64/aarch64-elf.exp: Run the new test.
Add a cast to reinterpret a void* as a gdb_byte*.
2016-02-09 Walfred Tedeschi <walfred.tedeschi@intel.com>
gdb/gdbserver/ChangeLog:
* linux-x86-low.c (x86_siginfo_fixup): Add cast to gdb_byte*.
bfd * elfnn-aarch64.c (elfNN_aarch64_relocate_section): Add a more
helpful warning message to explain why certain AArch64 relocs
might overflow.
ld * testsuite/ld-aarch64/reloc-overflow-bad.d: New test.
* testsuite/ld-aarch64/reloc-overflow-1.s: New source file.
* testsuite/ld-aarch64/reloc-overflow-2.s: New source file.
* testsuite/ld-aarch64/aarch64-elf.exp: Run the new test.
When running tests in parallel, each test puts its generated files in a
different directory, under "outputs". I think it would be nice if it
was always the case, as it would isolate the test cases a bit more. An
artifact created by a test wouldn't get overwritten by another test.
Also, it makes it easier to clean up. A lot of executables are left all
over the place because their names do not appear in gdb.*/Makefile. If
everything is in "outputs", then we just have to delete that directory
(which we already do).
At the same time it makes the gdb.foo directories and their Makefiles
useless in the build directory, since they are pretty much only used for
cleaning.
What do you think?
gdb/testsuite/ChangeLog:
* Makefile.in (ALL_SUBDIRS): Remove.
(clean mostlyclean): Do not recurse in ALL_SUBDIRS.
(distclean maintainer-clean realclean): Likewise.
* configure.ac (AC_OUTPUT): Remove gdb.*/Makefile.
* configure: Regenerate.
* gdb.ada/Makefile.in: Delete.
* gdb.arch/Makefile.in: Likewise.
* gdb.asm/Makefile.in: Likewise.
* gdb.base/Makefile.in: Likewise.
* gdb.btrace/Makefile.in: Likewise.
* gdb.cell/Makefile.in: Likewise.
* gdb.compile/Makefile.in: Likewise.
* gdb.cp/Makefile.in: Likewise.
* gdb.disasm/Makefile.in: Likewise.
* gdb.dlang/Makefile.in: Likewise.
* gdb.dwarf2/Makefile.in: Likewise.
* gdb.fortran/Makefile.in: Likewise.
* gdb.gdb/Makefile.in: Likewise.
* gdb.go/Makefile.in: Likewise.
* gdb.guile/Makefile.in: Likewise.
* gdb.java/Makefile.in: Likewise.
* gdb.linespec/Makefile.in: Likewise.
* gdb.mi/Makefile.in: Likewise.
* gdb.modula2/Makefile.in: Likewise.
* gdb.multi/Makefile.in: Likewise.
* gdb.objc/Makefile.in: Likewise.
* gdb.opencl/Makefile.in: Likewise.
* gdb.opt/Makefile.in: Likewise.
* gdb.pascal/Makefile.in: Likewise.
* gdb.perf/Makefile.in: Likewise.
* gdb.python/Makefile.in: Likewise.
* gdb.reverse/Makefile.in: Likewise.
* gdb.server/Makefile.in: Likewise.
* gdb.stabs/Makefile.in: Likewise.
* gdb.threads/Makefile.in: Likewise.
* gdb.trace/Makefile.in: Likewise.
* gdb.xml/Makefile.in: Likewise.
* lib/gdb.exp (make_gdb_parallel_path): Add check for
GDB_PARALLEL.
(standard_output_file): Remove check for GDB_PARALLEL, always
return path in outputs/$subdir/$testname.
While testing the following patch,
[PATCH] Always organize test artifacts in a directory hierarchy
https://sourceware.org/ml/gdb-patches/2016-01/msg00133.html
I noticed that it broke Ada testing. This lead me to think that
parallel testing when building in-tree didn't work previously in Ada.
It is confirmed by this test:
$ make check TESTS="gdb.ada/fun_addr.exp" -j 2
...
Running ./gdb.ada/fun_addr.exp ...
FAIL: gdb.ada/fun_addr.exp: compilation foo.adb
...
This patch fixes in-tree parallel testing for Ada, and consequently
serial and parallel testing when the aforementioned patch is applied.
The problem originates from the fact that Ada support code cd's to the
builddir before compiling. In itself it's not a problem, it allows to
place intermediate auto-generated files in that directory. The Ada
compilation refers to the source file, which is in another directory,
only by its base name (e.g. foo.adb). In serial mode, that worked
because builddir was the same as the source directory (e.g.
gdb.ada/fun_addr/). In an out-of-tree build, it works because the
source directory is added as an include directory (note: this is not the
same $srcdir as autoconf's):
set srcdir [file dirname $source]
additional_flags=-I$srcdir
which becomes:
additional_flags=-I/home/emaisin/build/binutils-gdb/gdb/testsuite/gdb.ada/fun_addr
However, when building in-tree, srcdir is relative: ./gdb.ada/fun_addr.
When using parallel or always-in-outputs-directory mode, we are cd'ed in
the outputs directory. So -I$srcdir is relative to the current
directory, which is wrong.
To fix it, I made the TCL variable srcdir (set in site.exp, from which
everything else is derived) always absolute. It is done by assigning
autoconf's abs_srcdir instead of autoconf's srcdir. This way -I$srcdir
will always be good, regardless of where we cd'ed to. A small apparent
change is that when running tests, DejaGnu will say:
Running /tmp/binutils-gdb/gdb/testsuite/gdb.ada/fun_addr.exp ...
instead of
Running ./gdb.ada/fun_addr.exp ...
I hope it's not too much of an annoyance. I think that it should make
the testsuite a tiny bit more robust against other bugs of the same
class.
Regtested in & out of tree, only with native target.
gdb/testsuite/ChangeLog:
* Makefile.in (abs_srcdir): Assign @abs_srcdir@.
(site.exp): Assign abs_srcdir to tcl's srcdir.
I built remote.c with -Wunused, to check a function I was working on,
turns out there is a bunch of unused variables.
gdb/ChangeLog:
* remote.c (remote_register_number_and_offset): Remove unused
variable(s).
(remote_thread_always_alive): Likewise.
(remote_update_thread_list): Likewise.
(process_initial_stop_replies): Likewise.
(remote_start_remote): Likewise.
(remote_check_symbols): Likewise.
(discard_pending_stop_replies): Likewise.
(process_stop_reply): Likewise.
(putpkt_binary): Likewise.
(getpkt): Likewise.
(remote_add_target_side_condition): Likewise.
(remote_insert_breakpoint): Likewise.
(remote_supports_stopped_by_sw_breakpoint): Likewise.
(remote_supports_stopped_by_hw_breakpoint): Likewise.
(remote_xfer_partial): Likewise.
(remote_read_btrace): Likewise.
(remote_async_serial_handler): Likewise.
(remote_thread_events): Likewise.
(_initialize_remote): Likewise.
On x32, a pc-relative reference to an undef weak symbol (value 0)
with a negative addend (typically -4) generates a spurious overflow
error because Symbol_value::value() returns a 32-bit negative number
as an unsigned number, which gets zero-extended before subtracting
the PC value. This patch fixes the problem by special-casing the
negative addend, and adding it to the value after widening it to
64 bits. Symbol_value::value() does not need the addend if it's
negative, since it is only important when processing section
symbols for merge sections, where a positive addend provides the
input section offset of the merged constant.
gold/
* x86_64.cc (X86_64_relocate_functions::pcrela32_check): Fix x32
overflow checking when symbol value + addend < 0.
This patch removes some dead code.
I noticed that varobj_delete was always called with dellist == NULL, so
I started removing that parameter. That allows removing a good chunk of
the code in varobj_delete, making it almost trivial. We can also remove
the resultp parameters in that whole trail. In turn, this shows that
struct cpstack, cppush and cppop were only used fo that mechanism, so
they can be removed as well.
I also moved the function comment to the header file to comply with
today's guideline, even though the rest of the file does not respect it
(yet).
gdb/ChangeLog:
* varobj.h (varobj_delete): Remove dellist parameter, update and
move documentation here.
* varobj.c (struct cpstack, cppush, cppop): Remove.
(delete_variable): Remove resultp (first) parameter.
(delete_variable_1): Likewise.
(varobj_delete): Remove dellist parameter and unused code.
(update_dynamic_varobj_children): Adjust varobj_delete call.
(update_type_if_necessary): Likewise.
(varobj_set_visualizer): Likewise.
(varobj_update): Likewise.
(value_of_root): Likewise.
(varobj_invalidate_iter): Likewise.
* mi/mi-cmd-var.c (mi_cmd_var_delete): Likewise.
In order to get around the optimizer and newer compiler warnings
about shift counts, the overflow checking code had resorted to
some messy shifting, and with the never-before-seen instantiations
of the template functions, we were still running afoul of the
compiler checks.
This patch replaces those messy shift sequences with a simple
class template that provides the min and max limits for any
bit size up to 64, with a specialization for 64 that prevents
the compiler from complaining.
gold/
PR gold/19577
* reloc.h (Limits): New class.
(Bits::has_overflow32): Use min/max values from Limits.
(Bits::has_unsigned_overflow32): Likewise.
(Bits::has_signed_unsigned_overflow32): Likewise.
(Bits::has_overflow): Likewise.
(Bits::has_unsigned_overflow): Likewise.
(Bits::has_signed_unsigned_overflow64): Likewise.
The problem here is that x32 is really using 64-bit addressing,
while pretending to be 32-bit. Even though the object file format
is 32-bit, we need to do the overflow checking with 64-bit
arithmetic (because that's what the hardware will be using).
This patch overrides the pcrela32_check functions in reloc.h
with target-specific versions that do 64-bit checking.
I've also updated the test case to use -Tdata instead of adding
a huge .space directive, to reduce the size of the .o files.
gold/
PR gold/19567
* reloc.h (Relocate_functions::Overflow_check): Add comments.
* x86_64.cc (X86_64_relocate_functions): New class.
(Target_x86_64::Relocate::relocate): Use the new class.
* testsuite/Makefile.am (x86_64_overflow_pc32): Add -Tdata option.
(x32_overflow_pc32): New test case.
* testsuite/Makefile.in: Regenerate.
* testsuite/x32_overflow_pc32.sh: New script.
* testsuite/x86_64_overflow_pc32.s: Remove .space directive.
This is needed by s390 split-stack support, to distinguish call
and load-address relocations.
gold/ChangeLog:
* i386.cc (Target_i386::is_call_to_non_split): Add view and view_size
parameters.
* reloc.cc (Sized_relobj_file::split_stack_adjust_reltype): Pass view
and view_size to is_call_to_non_split.
* target.cc (Target::is_call_to_non_split): Add view and view_size
parameters.
* target.h (class Target): Likewise.
* icf.cc (get_rel_addend): New function.
(get_section_contents): Move merge section addend computation to a
new function. Ignore negative values for SHT_REL and SHT_RELA addends.
Fix bug to not read past the length of the section.
Fix bug related to addend computation for MERGE sections.
* cgen-scache.c (scache_option_handler): Prevent possible
undefined behaviour computing the size of the scache by using
unsigned integers instead of signed integers.
BASEDIR was added by https://sourceware.org/ml/gdb-patches/2013-10/msg00587.html
in order to handle the different directory layout in serial testing
and parallel testing. BASEDIR is "gdb.base" in serial testing and is
"outputs/gdb.base/TESTNAME" in parallel testing. However, it doesn't
work if the GDBserver is in remote target, like this,
$ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost foll-vfork.exp foll-exec.exp'
FAIL: gdb.base/foll-exec.exp: continue to first exec catchpoint (the program exited)
FAIL: gdb.base/foll-vfork.exp: exec: vfork and exec child follow, to main bp: continue to bp (the program exited)
FAIL: gdb.base/foll-vfork.exp: exec: vfork child follow, finish after tcatch vfork: finish (the program exited)
FAIL: gdb.base/foll-vfork.exp: exec: vfork relations in info inferiors: continue to bp (the program exited)
these tests fail because the executable can't be found. With target
board native-gdbserver, the program is spawned this way,
spawn ../gdbserver/gdbserver --once :2347 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.base/foll-vfork
so BASEDIR is correct. However, with target board
remote-gdbserver-on-localhost, the program is spawned
spawn /usr/bin/ssh -l yao localhost /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../gdbserver/gdbserver --once :2346 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.base/foll-vfork
so BASEDIR (either "gdb.base" or "outputs/gdb.base/TESTNAME") makes no
sense.
I had a fix that pass absolute directory to BASEDIR, but it assumes
that directory structure is the same on build and target, and it
doesn't work in remote host case. The current fix in this patch is
to get the directory from argv[0]. In any case, the program to be
exec'ed is at the same directory with the main program.
Note that these tests do "next N" to let program stop at the desired
line, but it is fragile, because GDB for different targets may skip
function prologue slightly differently, so I replace some of them by
"tbreak on LINE NUMBER and continue".
gdb/testsuite:
2016-02-04 Yao Qi <yao.qi@linaro.org>
* gdb.base/foll-exec-mode.c: Include limits.h.
(main): Add parameters argc and argv. Get directory from
argv[0].
* gdb.base/foll-exec-mode.exp: Don't pass -DBASEDIR in
compilation.
* gdb.base/foll-exec.c: Include limits.h.
(main): Add parameters argc and argv.
Get directory from argv[0].
* gdb.base/foll-exec.exp: Don't pass -DBASEDIR in compilation.
Adjust tests on the number of lines as source code changed.
* gdb.base/foll-vfork-exit.c: Include limits.h.
(main): Add one line of statement before vfork.
* gdb.base/foll-vfork.c: Include limits.h and string.h.
(main): Add parameters argc and argv. Get directory from
argv[0].
* gdb.base/foll-vfork.exp: Don't pass -DBASEDIR in compilation.
(setup_gdb): Set tbreak to skip some source lines.
* gdb.multi/bkpt-multi-exec.c: Include limits.h.
(main): Add parameters argc and argv. Get directory from
argv[0].
* gdb.multi/bkpt-multi-exec.exp: Don't pass -DBASEDIR in
compilation.
* gdb.multi/multi-arch-exec.c: Include limits.h and string.h.
(main): Add parameters argc and argv. Get directory from
argv[0].
* gdb.multi/multi-arch-exec.exp: Don't pass -DBASEDIR in
compilation.
Hi,
I see this error when GDB connects with qemu,
(gdb) n
....
Sending packet: $vCont;c#a8...Ack
Packet received: Ffstat,00000001,f6fff038
Cannot execute this command while the target is running.
Use the "interrupt" command to stop the target
and then try again.
looks we don't set rs->waiting_for_stop_reply to zero
before handle fileio request,
#10 0x00000000005edb64 in target_write (len=64, offset=4143968312, buf=0x7fffffffd570 "\375\377\377\377", annex=0x0, object=TARGET_OBJECT_MEMORY,
ops=<optimised out>) at /home/yao/SourceCode/gnu/gdb/git/gdb/target.c:1922
#11 target_write_memory (memaddr=memaddr@entry=4143968312, myaddr=myaddr@entry=0x7fffffffd6a0 "", len=len@entry=64)
at /home/yao/SourceCode/gnu/gdb/git/gdb/target.c:1500
#12 0x00000000004b2b41 in remote_fileio_func_fstat (buf=0x127b258 "") at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:1037
#13 0x00000000004b1878 in do_remote_fileio_request (uiout=<optimised out>, buf_arg=buf_arg@entry=0x127b240)
at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:1204
#14 0x00000000005b8c7c in catch_exceptions_with_msg (func_uiout=<optimised out>, func=func@entry=0x4b1800 <do_remote_fileio_request>,
func_args=func_args@entry=0x127b240, gdberrmsg=gdberrmsg@entry=0x0, mask=mask@entry=RETURN_MASK_ALL)
at /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:187
#15 0x00000000005b8dea in catch_exceptions (uiout=<optimised out>, func=func@entry=0x4b1800 <do_remote_fileio_request>, func_args=func_args@entry=0x127b240,
mask=mask@entry=RETURN_MASK_ALL) at /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:167
#16 0x00000000004b2fff in remote_fileio_request (buf=0x127b240 "Xf6fff038,0:", ctrlc_pending_p=0) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:1255
#17 0x0000000000496f12 in remote_wait_as (ptid=..., status=0x7fffffffdb20, options=1) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:6997
however, we did set rs->waiting_for_stop_reply to zero before Luis's
patch https://sourceware.org/ml/gdb-patches/2015-10/msg00336.html
In fact, Luis's patch v1
https://sourceware.org/ml/gdb-patches/2015-08/msg00809.html is about
setting rs->waiting_for_stop_reply back to one after
remote_fileio_request, which is correct. However during the review, the
patch is changed and ends up with "not setting rs->waiting_for_stop_reply
to zero".
I manually test GDB, but I don't have a way to run regression tests.
gdb:
2016-02-04 Yao Qi <yao.qi@linaro.org>
* remote.c (remote_wait_as): Set rs->waiting_for_stop_reply to
0 before handling 'F' and set it back afterwards.
PR target/19561
opcdoe * msp430-dis.c (print_insn_msp430): Add a special case for
decoding an RRC instruction with the ZC bit set in the extension
word.
include * opcode/msp430.h (IGNORE_CARRY_BIT): New define.
(RRUX): Synthesise using case 2 rather than 7.
gas * config/tc-msp430.c (msp430_operands): Remove case 7. Use case 2
to handle encoding of RRUX instruction.
* testsuite/gas/msp430/msp430x.s: Add more tests of the extended
shift instructions.
* testsuite/gas/msp430/msp430x.d: Update expected disassembly.
Change 1058c7532d "Use signed data type for R_XTENSA_DIFF* relocation
offsets." changed signedness of BFD_RELOC_XTENSA_DIFF* relocations
substituted for BFD_RELOC_*. This made it impossible to encode arbitrary
8-, 16- and 32-bit values, which broke e.g. debug info encoding by .loc
directive. Revert this part and add test.
gas/
2016-02-03 Max Filippov <jcmvbkbc@gmail.com>
* config/tc-xtensa.c (md_apply_fix): Mark BFD_RELOC_XTENSA_DIFF*
substitutions for BFD_RELOC_* as unsigned.
* gas/testsuite/gas/xtensa/all.exp: Add loc to list of xtensa
tests.
* gas/testsuite/gas/xtensa/loc.d: New file: loc test result
patterns.
* gas/testsuite/gas/xtensa/loc.s: New file: loc test.
This change makes gas's notion of the msp430 dwarf2 address size match
that of gcc and gdb. This is needed so that the format of addresses
generated for DW_LNE_set_address in .debug_line will match the address
size for the compilation unit.
In gcc/config/msp430/msp430.h, it's set to 4:
#define DWARF2_ADDR_SIZE 4
Likewise in gdb/msp430-tdep.c:
set_gdbarch_dwarf2_addr_size (gdbarch, 4);
(As far as I can tell, however, GDB doesn't use this value when decoding
.debug_line. Instead, GDB uses the Pointer Size from the compilation
unit.)
readelf is able to seamlessly handle mismatches between these various
sizes by using the size of the DW_LNE_set_address instruction to
determine the address size. Another way to fix this problem is to
make GDB behave in a similar manner. In my opinion, GDB should detect
and inform the user about these mismatches; it's not clear to me if
it's correct for GDB to go ahead and read the address anyway when a
size mismatch is detected.
Without this change, addresses in .debug_line are encoded in two bytes
for some multilibs. When GDB reads the address for
DW_LNE_set_address, it uses the pointer size provided by the CU. When
these values don't match, GDB reads the wrong number of bytes. In the
cases that I've looked at, GDB is reading 4 bytes from a 2 byte
container, which results in a garbage address. GDB discards lines
which have a bogus address; the end result is that GDB records no line
number information for CUs which have a mismatch between the address
size (from the CU) and the format of the address used by
DW_LNE_set_address.
gas/ChangeLog:
* config/tc-msp430.h (DWARF2_ADDR_SIZE): Set to 4.
This is unused since 54eb231c4b, where
static arrays of ui_out_levels were replaced with vectors.
gdb/ChangeLog:
* ui-out.c (MAX_UI_OUT_LEVELS): Remove.
elf_x86_64_convert_load is very time consuming since it is called on
each input section and has a loop over input text sections to estimate
the branch distrance. We can store the estimated distrances in the
compressed_size field of the output section, which is only used to
decompress the compressed input section.
Before the patch, linking clang 3.9 takes 52 seconds. After the patch,
it only takes 2.5 seconds.
PR ld/19542
* elf64-x86-64.c (elf_x86_64_convert_load): Store the estimated
distrances in the compressed_size field of the output section.
This tightens the condition under which ld optimizes PIC entry code
to non-PIC.
bfd/
* elf64-ppc.c (ppc64_elf_relocate_section): Further restrict
ELFv2 entry optimization.
gold/
* powerpc.cc (relocate): Further restrict ELFv2 entry optimization.
