This fixes:
$ ./gdb -q -ex "set endian big" -ex "set architecture cris"
The target is assumed to be big endian
.../src/gdb/cris-tdep.c:4051: internal-error: cris_gdbarch_init: big endian byte order in info
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
The "set cris-version" command can likewise cause internal errors.
The gdbarch init routine should be returning 0 to reject the
architecture instead of internal erroring on user input.
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* cris-tdep.c (cris_gdbarch_init): Return 0 if the info's byte
order is BFD_ENDIAN_BIG or if the cris version is unsupported.
Running the testsuite with a gdb configured with --enable-libmcheck
reveals a problem:
(gdb) ptype 3 * 2.0
type = <12-byte float>
memory clobbered past end of allocated block
ERROR: Process no longer exists
UNRESOLVED: gdb.ada/ptype_arith_binop.exp: ptype 3 * 2.0
(gdb) PASS: gdb.dlang/expression.exp: ptype 0x1.FFFFFFFFFFFFFp1023
ptype 0x1p-52L
type = real
memory clobbered past end of allocated block
ERROR: Process no longer exists
UNRESOLVED: gdb.dlang/expression.exp: ptype 0x1p-52L
Even though this shows up with Ada and D, it's easy to reproduce in C
too. We just need to print a long double, when the current arch is
32-bit, which is the default when gdb starts up:
$ ./gdb -q -ex "ptype 1.0L"
type = long double
memory clobbered past end of allocated block
Aborted (core dumped)
Valgrind shows:
==22159== Invalid write of size 8
==22159== at 0x8464A9: floatformat_from_doublest (doublest.c:756)
==22159== by 0x846822: store_typed_floating (doublest.c:867)
==22159== by 0x6A7959: value_from_double (value.c:3662)
==22159== by 0x6A9F2D: evaluate_subexp_standard (eval.c:745)
==22159== by 0x7F31AF: evaluate_subexp_c (c-lang.c:716)
==22159== by 0x6A8986: evaluate_subexp (eval.c:79)
==22159== by 0x6A8BA3: evaluate_type (eval.c:174)
==22159== by 0x817CCF: whatis_exp (typeprint.c:456)
==22159== by 0x817EAA: ptype_command (typeprint.c:508)
==22159== by 0x5F267B: do_cfunc (cli-decode.c:105)
==22159== by 0x5F5618: cmd_func (cli-decode.c:1885)
==22159== by 0x83622A: execute_command (top.c:475)
==22159== Address 0x8c6cb28 is 8 bytes inside a block of size 12 alloc'd
==22159== at 0x4C2AA98: calloc (vg_replace_malloc.c:711)
==22159== by 0x87384A: xcalloc (common-utils.c:83)
==22159== by 0x873889: xzalloc (common-utils.c:93)
==22159== by 0x6A34CB: allocate_value_contents (value.c:1036)
==22159== by 0x6A3501: allocate_value (value.c:1047)
==22159== by 0x6A790A: value_from_double (value.c:3656)
==22159== by 0x6A9F2D: evaluate_subexp_standard (eval.c:745)
==22159== by 0x7F31AF: evaluate_subexp_c (c-lang.c:716)
==22159== by 0x6A8986: evaluate_subexp (eval.c:79)
==22159== by 0x6A8BA3: evaluate_type (eval.c:174)
==22159== by 0x817CCF: whatis_exp (typeprint.c:456)
==22159== by 0x817EAA: ptype_command (typeprint.c:508)
==22159==
type = long double
(gdb)
Even if the target and host floating-point formats match, the length
of the types might still be different. On x86, long double is the
80-bit extended precision type on both 32-bit and 64-bit ABIs, but by
default it is stored as 12 bytes on 32-bit, and 16 bytes on 64-bit,
for alignment reasons. Several places in doublest.c already consider
this, but floatformat_to_doublest and floatformat_from_doublest miss
it. E.g., convert_typed_floating and store_typed_floating,
Tested on x86-64 Fedora 23 with --enable-libmcheck, where it fixes the
crashed above.
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* doublest.c: Extend comments.
(floatformat_to_doublest, floatformat_from_doublest): Copy the
floatformat's total size, not the host type's size.
This would have caught the HP/PA bug fixed in the previous patch:
.../src/gdb/gdbtypes.c:4690: internal-error: arch_float_type: Assertion `len >= floatformat_totalsize_bytes (floatformats[0])' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
Tested on x86-64 Fedora 23, --enable-targets=all.
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* doublest.c (floatformat_totalsize_bytes): New function.
(floatformat_from_type): Assert that the type's length is at least
as long as the floatformat's totalsize.
* doublest.h (floatformat_totalsize_bytes): New declaration.
* gdbtypes.c (arch_float_type): Assert that the type's length is
at least as long as the floatformat's totalsize.
This:
$ ./gdb -ex "set architecture hppa1.0" -ex "set osabi GNU/Linux" -ex "ptype 1.0L"
Shows that HPPA/Linux support for long doubles is broken. It causes
GDB to access memory out of bounds. With Valgrind, we see:
The target architecture is assumed to be hppa1.0
==4371== Invalid write of size 8
==4371== at 0x4C2F21F: memset (vg_replace_strmem.c:1224)
==4371== by 0x8451C4: convert_doublest_to_floatformat (doublest.c:362)
==4371== by 0x845F86: floatformat_from_doublest (doublest.c:769)
==4371== by 0x84628E: store_typed_floating (doublest.c:873)
==4371== by 0x6A7C3D: value_from_double (value.c:3662)
==4371== by 0x6AA211: evaluate_subexp_standard (eval.c:745)
==4371== by 0x7F306D: evaluate_subexp_c (c-lang.c:716)
==4371== by 0x6A8C6A: evaluate_subexp (eval.c:79)
==4371== by 0x6A8E87: evaluate_type (eval.c:174)
==4371== by 0x817B8D: whatis_exp (typeprint.c:456)
==4371== by 0x817D68: ptype_command (typeprint.c:508)
==4371== by 0x5F2977: do_cfunc (cli-decode.c:105)
==4371== Address 0x8998d18 is 0 bytes after a block of size 8 alloc'd
==4371== at 0x4C2AA98: calloc (vg_replace_malloc.c:711)
==4371== by 0x8732B6: xcalloc (common-utils.c:83)
==4371== by 0x8732F5: xzalloc (common-utils.c:93)
==4371== by 0x6A37AF: allocate_value_contents (value.c:1036)
==4371== by 0x6A37E5: allocate_value (value.c:1047)
==4371== by 0x6A7BEE: value_from_double (value.c:3656)
==4371== by 0x6AA211: evaluate_subexp_standard (eval.c:745)
==4371== by 0x7F306D: evaluate_subexp_c (c-lang.c:716)
==4371== by 0x6A8C6A: evaluate_subexp (eval.c:79)
==4371== by 0x6A8E87: evaluate_type (eval.c:174)
==4371== by 0x817B8D: whatis_exp (typeprint.c:456)
==4371== by 0x817D68: ptype_command (typeprint.c:508)
The trouble is that hppa_linux_init_abi overrides the default
long_double_bit set by the generic hppa-tdep.c:
set_gdbarch_long_double_bit (gdbarch, 128);
set_gdbarch_long_double_format (gdbarch, floatformats_ia64_quad);
with:
/* On hppa-linux, currently, sizeof(long double) == 8. There has been
some discussions to support 128-bit long double, but it requires some
more work in gcc and glibc first. */
set_gdbarch_long_double_bit (gdbarch, 64);
which misses overriding the long_double_format, so we end with a weird
combination of:
set_gdbarch_long_double_bit (gdbarch, 64);
set_gdbarch_long_double_format (gdbarch, floatformats_ia64_quad);
Weird because floatformats_ia64_quad's totalsize is longer than 64-bits.
The floatformat conversion routines use the struct floatformat's
totalsize (in bits) to know how much to copy/convert, thus the buffer
overruns.
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* hppa-linux-tdep.c (hppa_linux_init_abi): Set the long double
format to floatformats_ieee_double.
This patch is a simple refactoring that will allow the MIPS backend to
replace the Output_data_reloc_base::do_write() method without copying
its entire implementation. I've moved the implementation of do_write()
into a function template, which can be instantiated with a custom
class to write the MIPS-specific relocation format. The custom class
for MIPS needs access to the symbol index and address from
Output_reloc, so I've included the part of Vlad's MIPS-64 patch that
makes those accessor methods public.
2016-03-08 Cary Coutant <ccoutant@gmail.com>
Vladimir Radosavljevic <vladimir.radosavljevic@imgtec.com>
gold/
* output.cc (Output_reloc_writer): New type.
(Output_data_reloc_base::do_write): Move implementation to template
in output.h and replace with invocation of template.
* output.h (Output_file): Move to top of file.
(Output_reloc::get_symbol_index): Move to public interface.
(Output_reloc::get_address): Likewise.
(Output_data_reloc_base::do_write_generic): New function template.
Increment PLT reference count for locally defined local IFUNC symbols
in shared object since STT_GNU_IFUNC symbol must go through PLT even
if it is locally defined and undefined symbol may turn out to be a
STT_GNU_IFUNC symbol later.
bfd/
PR ld/19784
* elf32-i386.c (elf_i386_check_relocs): Increment PLT reference
count for locally defined local IFUNC symbols in shared object.
* elf64-x86-64.c (elf_x86_64_check_relocs): Likewise.
ld/
PR ld/19784
* testsuite/ld-i386/i386.exp: Remove pr19636-2e-nacl test.
* testsuite/ld-i386/pr19636-2e-nacl.d: Moved to ...
* testsuite/ld-i386/pr19636-2e.d: Here. Remove notarget.
* testsuite/ld-ifunc/ifunc.exp: Run PR ld/19784 tests.
* testsuite/ld-ifunc/pass.out: New file.
* testsuite/ld-ifunc/pr19784a.c: Likewise.
* testsuite/ld-ifunc/pr19784b.c: Likewise.
* testsuite/ld-ifunc/pr19784c.c: Likewise.
Since compiler may pass --as-needed to ld by default, link .o file
before .so file in ifunc tests.
PR ld/19774
* testsuite/ld-ifunc/ifunc.exp: Link tmpdir/pr18808a.o before
tmpdir/libpr18808.so. Link tmpdir/pr18841a.o before
tmpdir/libpr18841b.so and tmpdir/libpr18841c.so. Test
--as-needed for pr18841c.
bfd/
2016-03-08 Cupertino Miranda <Cupertino.Miranda@synopsys.com>
Andrew Burgess <andrew.burgess@embecosm.com>
* elf32-arc.c (arc_bfd_get_32): Becomes an alias for bfd_get_32.
(arc_bfd_put_32): Becomes an alias for bfd_put_32.
(arc_elf_howto_init): Added assert to validate relocations.
(get_middle_endian_relocation): Delete.
(middle_endian_convert): New function.
(ME): Redefine, now does nothing.
(IS_ME): New define.
(arc_do_relocation): Extend the attached 'ARC_RELOC_HOWTO'
definition to call middle_endian_convert. Add a new local
variable and make use of this throughout. Added call to
arc_bfd_get_8 and arc_bfd_put_8 for 8 bit relocations.
gas/
2016-03-08 Andrew Burgess <andrew.burgess@embecosm.com>
* testsuite/gas/arc/inline-data-1.d: New file.
* testsuite/gas/arc/inline-data-1.s: New file.
include/
2016-03-08 Cupertino Miranda <Cupertino.Miranda@synopsys.com>
Andrew Burgess <andrew.burgess@embecosm.com>
* elf/arc-reloc.def: Add a call to ME within the formula for each
relocation that requires middle-endian correction.
bfd PR binutils/19775
* archive.c (bfd_generic_openr_next_archived_file): Allow zero
length elements in the archive.
binutils PR binutils/19775
* testsuite/binutils-all/ar.exp (proc empty_archive): New proc.
Run the new proc.
* testsuite/binutils-all/empty: New, empty, file.
Since compiler may pass --as-needed to ld by default, link .o file
before .so file in i386/x86-64 tests.
PR ld/19774
* testsuite/ld-i386/i386.exp: Link tmpdir/pr18900.o before
tmpdir/pr18900.so and test --as-needed. Link tmpdir/gotpc1.o
before tmpdir/got1d.so and test --as-needed.
* testsuite/ld-x86-64/x86-64.exp: Link tmpdir/pr18900.o before
tmpdir/pr18900.so and test --as-needed.
Fix this GDB crash:
$ gdb -ex "set architecture mips:10000"
Segmentation fault (core dumped)
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000495b1b in mips_gdbarch_init (info=..., arches=0x0) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/mips-tdep.c:8436
8436 if (bfd_get_flavour (info.abfd) == bfd_target_elf_flavour
(top-gdb) bt
#0 0x0000000000495b1b in mips_gdbarch_init (info=..., arches=0x0) at .../src/gdb/mips-tdep.c:8436
#1 0x00000000007348a6 in gdbarch_find_by_info (info=...) at .../src/gdb/gdbarch.c:5155
#2 0x000000000073563c in gdbarch_update_p (info=...) at .../src/gdb/arch-utils.c:522
#3 0x0000000000735585 in set_architecture (ignore_args=0x0, from_tty=1, c=0x26bc870) at .../src/gdb/arch-utils.c:496
#4 0x00000000005f29fd in do_sfunc (c=0x26bc870, args=0x0, from_tty=1) at .../src/gdb/cli/cli-decode.c:121
#5 0x00000000005fd3f3 in do_set_command (arg=0x7fffffffdcdd "mips:10000", from_tty=1, c=0x26bc870) at .../src/gdb/cli/cli-setshow.c:455
#6 0x0000000000836157 in execute_command (p=0x7fffffffdcdd "mips:10000", from_tty=1) at .../src/gdb/top.c:460
#7 0x000000000071abfb in catch_command_errors (command=0x835f6b <execute_command>, arg=0x7fffffffdccc "set architecture mips:10000", from_tty=1)
at .../src/gdb/main.c:368
#8 0x000000000071bf4f in captured_main (data=0x7fffffffd750) at .../src/gdb/main.c:1132
#9 0x0000000000716737 in catch_errors (func=0x71af44 <captured_main>, func_args=0x7fffffffd750, errstring=0x106b9a1 "", mask=RETURN_MASK_ALL)
at .../src/gdb/exceptions.c:240
#10 0x000000000071bfe6 in gdb_main (args=0x7fffffffd750) at .../src/gdb/main.c:1164
#11 0x000000000040a6ad in main (argc=4, argv=0x7fffffffd858) at .../src/gdb/gdb.c:32
(top-gdb)
We already check whether info.abfd is NULL before all other
bfd_get_flavour calls in the same function. Just this one case was
missing.
(This was exposed by a WIP test that tries all "set architecture ARCH"
values.)
gdb/ChangeLog:
2016-03-07 Pedro Alves <palves@redhat.com>
* mips-tdep.c (mips_gdbarch_init): Check whether info.abfd is NULL
before calling bfd_get_flavour.
2016-03-07 Jiong Wang <jiong.wang@arm.com>
bfd/
* elfnn-aarch64.c (elfNN_aarch64_check_relocs): Always create .got section
if the symbol "_GLOBAL_OFFSET_TABLE_" referenced.
ld/
* testsuite/ld-aarch64/implicit_got_section_1.s: New test source file.
* testsuite/ld-aarch64/implicit_got_section_1.d: New test expected result.
* testsuite/ld-aarch64/aarch64-elf.exp: Run new test.
I forgot to do it in my previous commit. This is necessary because we
execute the script directly on gdb/testsuite/Makefile.in.
gdb/testsuite/ChangeLog:
2016-03-06 Sergio Durigan Junior <sergiodj@redhat.com>
* analyze-racy-logs.py: Set executable bit.
Since compiler may pass --as-needed to ld by default, link
tmpdir/copyreloc-main.o before tmpdir/copyreloc-lib.so.
* testsuite/ld-i386/i386.exp: Link tmpdir/copyreloc-main.o
before tmpdir/copyreloc-lib.so and test --as-needed.
* testsuite/ld-x86-64/x86-64.exp: Likewise.
This is an initial attempt to introduce some mechanisms to identify
racy testcases present in our testsuite. As can be seen in previous
discussions, racy tests are really bothersome and cause our BuildBot
to pollute the gdb-testers mailing list with hundreds of
false-positives messages every month. Hopefully, identifying these
racy tests in advance (and automatically) will contribute to the
reduction of noise traffic to gdb-testers, maybe to the point where we
will be able to send the failure messages directly to the authors of
the commits.
I spent some time trying to decide the best way to tackle this
problem, and decided that there is no silver bullet. Racy tests are
tricky and it is difficult to catch them, so the best solution I could
find (for now?) is to run our testsuite a number of times in a row,
and then compare the results (i.e., the gdb.sum files generated during
each run). The more times you run the tests, the more racy tests you
are likely to detect (at the expense of waiting longer and longer).
You can also run the tests in parallel, which makes things faster (and
contribute to catching more racy tests, because your machine will have
less resources for each test and some of them are likely to fail when
this happens). I did some tests in my machine (8-core i7, 16GB RAM),
and running the whole GDB testsuite 5 times using -j6 took 23 minutes.
Not bad.
In order to run the racy test machinery, you need to specify the
RACY_ITER environment variable. You will assign a number to this
variable, which represents the number of times you want to run the
tests. So, for example, if you want to run the whole testsuite 3
times in parallel (using 2 cores), you will do:
make check RACY_ITER=3 -j2
It is also possible to use the TESTS variable and specify which tests
you want to run:
make check TEST='gdb.base/default.exp' RACY_ITER=3 -j2
And so on. The output files will be put at the directory
gdb/testsuite/racy_outputs/.
After make invokes the necessary rules to run the tests, it finally
runs a Python script that will analyze the resulting gdb.sum files.
This Python script will read each file, and construct a series of sets
based on the results of the tests (one set for FAIL's, one for
PASS'es, one for KFAIL's, etc.). It will then do some set operations
and come up with a list of unique, sorted testcases that are racy.
The algorithm behind this is:
for state in PASS, FAIL, XFAIL, XPASS...; do
if a test's state in every sumfile is $state; then
it is not racy
else
it is racy
(The algorithm is actually a bit more complex than that, because it
takes into account other things in order to decide whether the test
should be ignored or not).
IOW, a test must have the same state in every sumfile.
After processing everything, the script prints the racy tests it could
identify on stdout. I am redirecting this to a file named racy.sum.
Something else that I wasn't sure how to deal with was non-unique
messages in our testsuite. I decided to do the same thing I do in our
BuildBot: include a unique identifier in the end of message, like:
gdb.base/xyz.exp: non-unique message
gdb.base/xyz.exp: non-unique message <<2>>
This means that you will have to be careful about them when you use
the racy.sum file.
I ran the script several times here, and it did a good job catching
some well-known racy tests. Overall, I am satisfied with this
approach and I think it will be helpful to have it upstream'ed. I
also intend to extend our BuildBot and create new, specialized
builders that will be responsible for detecting the racy tests every X
number of days.
2016-03-05 Sergio Durigan Junior <sergiodj@redhat.com>
* Makefile.in (DEFAULT_RACY_ITER): New variable.
(CHECK_TARGET_TMP): Likewise.
(check-single-racy): New rule.
(check-parallel-racy): Likewise.
(TEST_TARGETS): Adjust rule to account for RACY_ITER.
(do-check-parallel-racy): New rule.
(check-racy/%.exp): Likewise.
* README (Racy testcases): New section.
* analyze-racy-logs.py: New file.
When calling function with argument of size more than 8 bytes fails with
an error "That operation is not available on integers of more than 8 bytes.".
avr-gdb considers only 8 bytes (sizeof(long long)) in case of passing the
argument in registers. When the argument is of size more than 8 byte
then the utility function to extract bytes failed with the above error.
gdb/
* avr-tdep.c (AVR_LAST_ARG_REGNUM): Define.
(avr_push_dummy_call): Correct last needed argument register.
Write MSB of argument into register and subsequent bytes into
other registers in decreasing order.
ARM process record gets the wrong register number for VMOV (from core
register to single-precision register). That is, we should record
the D register rather than the S pseudo register. The patch also
removes the condition "bit (arm_insn_r->arm_insn, 20)" check, which
has been checked above.
It fixes the following internal error,
(gdb) PASS: gdb.reverse/finish-precsave.exp: BP at end of main
continue^M
Continuing.^M
../../binutils-gdb/gdb/regcache.c:649: internal-error: regcache_raw_read: Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed.^M
A problem internal to GDB has been detected,FAIL: gdb.reverse/finish-precsave.exp: run to end of main (GDB internal error)
gdb:
2016-03-04 Yao Qi <yao.qi@linaro.org>
* arm-tdep.c (arm_record_vdata_transfer_insn): Simplify the
condition check. Record the right D register number.
This patch removes the printing "Process record does not support",
and do the print by calling arm_record_unsupported_insn in the
caller. Also, call arm_record_extension_space only when condition
is 0xf.
gdb:
2016-03-04 Yao Qi <yao.qi@linaro.org>
* arm-tdep.c (arm_record_extension_space): Remove code
printing "Process record does not support".
(arm_record_data_proc_misc_ld_str): Likewise.
(decode_insn): Call arm_record_extension_space if condition
is 0xf. Call arm_record_unsupported_insn if ret isn't
ARM_RECORD_SUCCESS. Use 'ret' instead of 'insn_id' to hold
the value of thumb2_record_decode_insn_handler.
I found that odd that passing no arguments to feature_to_c.sh produces
this:
$ ./feature_to_c.sh
./feature_to_c.sh: 23: shift: can't shift that many
but passing one argument shows the help:
$ ./feature_to_c.sh hello
Usage: ./feature_to_c.sh OUTPUTFILE INPUTFILE...
This patch changes the script to show the help in both cases.
gdb/ChangeLog:
* features/feature_to_c.sh: Print the help when passing no
argument.
Common symbol in executable is a definition, which overrides definition
from shared objects. When linker sees a new definition from a shared
object, the new dynamic definition should be overridden by the previous
common symbol in executable.
bfd/
PR ld/19579
* elflink.c (_bfd_elf_merge_symbol): Treat common symbol in
executable as definition if the new definition comes from a
shared library.
ld/
PR ld/19579
* testsuite/ld-elf/pr19579a.c: New file.
* testsuite/ld-elf/pr19579b.c: Likewise.
* testsuite/ld-elf/shared.exp: Run PR ld/19579 test.
gold/
PR gold/19019
* layout.h (Layout::add_target_specific_dynamic_tag): New function.
* layout.cc (Layout::add_target_specific_dynamic_tag): New function.
* mips.cc (Target_mips::make_symbol): Adjust function signature.
* sparc.cc (Target_sparc::Target_sparc): Initialize register_syms_.
(Target_sparc::do_is_defined_by_abi): Remove test for
STT_SPARC_REGISTER.
(Target_sparc::Register_symbol): New struct type.
(Target_sparc::register_syms_): New data member.
(Target_sparc<64, true>::sparc_info): Set has_make_symbol to true.
(Target_sparc::make_symbol): New function.
(Target_sparc::do_finalize_sections): Add register symbols and new
dynamic table entries.
* symtab.h (Sized_symbol::init_undefined): Add value parameter.
(Symbol_table::add_target_global_symbol): New function.
(Symbol_table::target_symbols_): New data member.
* symtab.cc (Sized_symbol::init_undefined): Add value parameter.
(Symbol_table::Symbol_table): Initialize target_symbols_.
(Symbol_table::add_from_object): Pass additional parameters to
Target::make_symbol.
(Symbol_table::define_special_symbol): Likewise.
(Symbol_table::add_undefined_symbol_from_command_line): Pass 0 for
undefined symbol value.
(Symbol_table::set_dynsym_indexes): Process target-specific symbols.
(Symbol_table::sized_finalize): Likewise.
(Symbol_table::sized_write_globals): Likewise.
* target.h (Sized_target::make_symbol): Add name, st_type, object,
st_shndx, and value parameters.
include/
2016-03-03 Than McIntosh <thanm@google.com>
* plugin-api.h: Add new hooks to the plugin transfer vector to
to support querying section alignment and section size.
(ld_plugin_get_input_section_alignment): New hook.
(ld_plugin_get_input_section_size): New hook.
(ld_plugin_tag): Add LDPT_GET_INPUT_SECTION_ALIGNMENT
and LDPT_GET_INPUT_SECTION_SIZE.
(ld_plugin_tv): Add tv_get_input_section_alignment and
tv_get_input_section_size.
gold/
2016-03-03 Than McIntosh <thanm@google.com>
* plugin.cc (Plugin::load): Include hooks for get_input_section_size
and get_input_section_alignment in transfer vector.
(get_input_section_alignment): New function.
(get_input_section_size): New function.
* testsuite/Makefile.am: Add plugin_layout_with_alignment.sh test.
* testsuite/Makefile.in: [Regenerate.]
* testsuite/plugin_section_alignment.cc: New test file.
* testsuite/plugin_layout_with_alignment.cc: New test file.
* testsuite/plugin_layout_with_alignment.sh: New test file.
Let the plugin know that a file is not being included in the link by
returning LDPS_NO_SYMS from get_symbols().
include/
* plugin-api.h (enum ld_plugin_tag): Add LDPT_GET_SYMBOLS_V3.
gold/
* plugin.h (Pluginobj::get_symbol_resolution_info): Add version
parameter.
* plugin.cc (get_symbols_v3): New function.
(Plugin::load): Add LDPT_GET_SYMBOLS_V3.
(Pluginobj::get_symbol_resolution_info): Return LDPS_NO_SYMS when using
new version.
* simulator.c (set_flags_for_sub32): Correct type of signbit.
(CondCompare): Swap interpretation of bit 30.
(DO_ADDP): Delete macro.
(do_vec_ADDP): Copy source registers before starting to update
destination register.
(do_vec_FADDP): Likewise.
(do_vec_load_store): Fix computation of sizeof_operation.
(rbit64): Fix type of constant.
(aarch64_step): When displaying insn value, display all 32 bits.
I happen to see that comments to start_step_over isn't in sync with
code, so this patch is to update the comments.
gdb/gdbserver:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* linux-low.c: Update comments to start_step_over.
This patch adds a new test for stepping over clone syscall.
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/step-over-syscall.exp (step_over_syscall): Kfail.
Invoke step_over_syscall "clone" and break_cond_on_syscall
"clone".
* gdb.base/step-over-clone.c: New file.
disp-step-syscall.exp is extended for stepping over syscall instruction
in different cases, with or without displaced stepping, and stepping
over by GDBserver.
This patch rename disp-step-syscall.exp to step-over-syscall.exp to
reflect this.
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-fork.c: Rename to ...
* gdb.base/step-over-fork.c: ... it. New file.
* gdb.base/disp-step-vfork.c: Rename to ...
* gdb.base/step-over-vfork.c: ... it. New file.
* gdb.base/disp-step-syscall.exp: Rename to ...
* gdb.base/step-over-syscall.exp: ... it. New file.
(disp_step_cross_syscall): Rename to ...
(step_over_syscall): ... it.
We can also extend disp-step-syscall.exp to test GDBserver step over
breakpoint on syscall instruction. That is, we set a breakpoint
with a false condition on syscall instruction, so that GDBserver will
step over it.
This test triggers a GDBserver internal error, which can be fixed by
this series.
(gdb) PASS: gdb.base/disp-step-syscall.exp: fork: break cond on target: break on syscall insns
continue^M
Continuing.^M
Remote connection closed^M
(gdb) FAIL: gdb.base/disp-step-syscall.exp: fork: break cond on target: continue to fork again
In GDBserver, there is an internal error,
/home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/linux-low.c:1922: A problem internal to GDBserver has been detected.
unsuspend LWP 25554, suspended=-1
the simplified reproducer is like,
$ ./gdb ./testsuite/outputs/gdb.base/disp-step-syscall/disp-step-fork
(gdb) b main
(gdb) c
(gdb) disassemble fork // in order to find the address of insn 'syscall'
....
0x00007ffff7ad6023 <+179>: syscall
(gdb) b *0x00007ffff7ad6023 if main == 0
(gdb) c
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-syscall.exp (break_cond_on_syscall): New.
If target supports condition evaluation on target, invoke
break_cond_on_syscall for fork and vfork.
disp-step-syscall.exp was added to test displaced stepping over syscall
instructions, in which we set breakpoint on syscall instruction, and
step over it. In fact, we can extend the test to non-displaced-stepping
case. This patch wraps the test with displaced stepping on and off.
Note that the indentation and format isn't adjusted here to make this
patch easy to read. The following patch will fix the format separately.
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-syscall.exp: Don't invoke
support_displaced_stepping.
(disp_step_cross_syscall): Test with displaced stepping off and
on if supported.
This patch moves some code out of disp_step_cross_syscall to a new proc
check_pc_after_cross_syscall and setup. Procedure setup is to start a
fresh GDB and compute the syscall instruction address.
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-syscall.exp (check_pc_after_cross_syscall): New
proc.
(setup): New proc.
(disp_step_cross_syscall): Move code to check_pc_after_cross_syscall
and setup.
I see the following GDBserver internal error in two cases,
gdb/gdbserver/linux-low.c:1922: A problem internal to GDBserver has been detected.
unsuspend LWP 17200, suspended=-1
1. step over a breakpoint on fork/vfork syscall instruction,
2. step over a breakpoint on clone syscall instruction and child
threads hits a breakpoint,
the stack backtrace is
#0 internal_error (file=file@entry=0x44c4c0 "gdb/gdbserver/linux-low.c", line=line@entry=1922,
fmt=fmt@entry=0x44c7d0 "unsuspend LWP %ld, suspended=%d\n") at gdb/gdbserver/../common/errors.c:51
#1 0x0000000000424014 in lwp_suspended_decr (lwp=<optimised out>, lwp=<optimised out>) at gdb/gdbserver/linux-low.c:1922
#2 0x000000000042403a in unsuspend_one_lwp (entry=<optimised out>, except=0x66e8c0) at gdb/gdbserver/linux-low.c:2885
#3 0x0000000000405f45 in find_inferior (list=<optimised out>, func=func@entry=0x424020 <unsuspend_one_lwp>, arg=arg@entry=0x66e8c0)
at gdb/gdbserver/inferiors.c:243
#4 0x00000000004297de in unsuspend_all_lwps (except=0x66e8c0) at gdb/gdbserver/linux-low.c:2895
#5 linux_wait_1 (ptid=..., ourstatus=ourstatus@entry=0x665ec0 <last_status>, target_options=target_options@entry=0)
at gdb/gdbserver/linux-low.c:3632
#6 0x000000000042a764 in linux_wait (ptid=..., ourstatus=0x665ec0 <last_status>, target_options=0)
at gdb/gdbserver/linux-low.c:3770
#7 0x0000000000411163 in mywait (ptid=..., ourstatus=ourstatus@entry=0x665ec0 <last_status>, options=options@entry=0, connected_wait=connected_wait@entry=1)
at gdb/gdbserver/target.c:214
#8 0x000000000040b1f2 in resume (actions=0x66f800, num_actions=1) at gdb/gdbserver/server.c:2757
#9 0x000000000040f660 in handle_v_cont (own_buf=0x66a630 "vCont;c:p45e9.-1") at gdb/gdbserver/server.c:2719
when GDBserver steps over a thread, other threads have been suspended,
the "stepping" thread may create new thread, but GDBserver doesn't set
it suspend count to 1. When GDBserver unsuspend threads, the child's
suspend count goes to -1, and the assert is triggered. In fact, GDBserver
has already taken care of suspend count of new thread when GDBserver is
suspending all threads except the one GDBserver wants to step over by
https://sourceware.org/ml/gdb-patches/2015-07/msg00946.html
+ /* If we're suspending all threads, leave this one suspended
+ too. */
+ if (stopping_threads == STOPPING_AND_SUSPENDING_THREADS)
+ {
+ if (debug_threads)
+ debug_printf ("HEW: leaving child suspended\n");
+ child_lwp->suspended = 1;
+ }
but that is not enough, because new thread is still can be spawned in
the thread which is being stepped over. This patch extends the
condition that GDBserver set child's suspend count to one if it is
suspending threads or stepping over the thread.
gdb/gdbserver:
2016-03-03 Yao Qi <yao.qi@linaro.org>
PR server/19736
* linux-low.c (handle_extended_wait): Set child suspended
if event_lwp->bp_reinsert isn't zero.
ld-elf/pr19162.d fails for hppa-*-* since Dave Anglin's fix for PR 12376
makes the data segment always start on a page boundary.
* testsuite/ld-elf/pr19162.d: Skip hppa-*-*.
