1. 04 Dec, 2020 20 commits
    • Simon Marchi's avatar
      gdb: restore displaced step buffer bytes when another thread forks · c0aba012
      Simon Marchi authored
      In handle_inferior_event, where we handle forks, we make sure to restore
      the bytes of the displaced stepping buffer in the child's address
      space.  However, we only do it when the forking thread was the one
      doing a displaced step.  It could happen that a thread forks while
      another one is doing a displaced step.  In this case, we also need to
      restore the bytes in the child.
      
      Move the byte-restoring code outside of the condition that checks
      whether the event thread was displaced stepping.
      
      gdb/ChangeLog:
      
      	* infrun.c (handle_inferior_event): Restore displaced step
      	buffer bytes in child process when handling fork, even if fork
      	happened in another thread than the displaced-stepping one.
      
      Change-Id: Ibb0daaeb123aba03f4fb4b4d820754eb2436bc69
      c0aba012
    • Simon Marchi's avatar
      gdb: clear inferior displaced stepping state and in-line step-over info on exec · 3b7a962d
      Simon Marchi authored
      When a process does an exec, all its program space is replaced with the
      newly loaded executable.  All non-main threads disappear and the main
      thread starts executing at the entry point of the new executable.
      
      Things can go wrong if a displaced step operation is in progress while
      we process the exec event.
      
      If the main thread is the one executing the displaced step: when that
      thread (now executing in the new executable) stops somewhere (say, at a
      breakpoint), displaced_step_fixup will run and clear up the state.  We
      will execute the "fixup" phase for the instruction we single-stepped in
      the old program space.  We are now in a completely different context,
      so doing the fixup may corrupt the state.
      
      If it is a non-main thread that is doing the displaced step: while
      handling the exec event, GDB deletes the thread_info representing that
      thread (since the thread doesn't exist in the inferior after the exec).
      But inferior::displaced_step_state::step_thread will still point to it.
      When handling events later, this condition, in displaced_step_fixup,
      will likely never be true:
      
          /* Was this event for the thread we displaced?  */
          if (displaced->step_thread != event_thread)
            return 0;
      
      ... since displaced->step_thread points to a deleted thread (unless that
      storage gets re-used for a new thread_info, but that wouldn't be good
      either).  This effectively makes the displaced stepping buffer occupied
      for ever.  When a thread in the new program space will want to do a
      displaced step, it will wait for ever.
      
      I think we simply need to reset the displaced stepping state of the
      inferior on exec.  Everything execution-related that existed before the
      exec is now gone.
      
      Similarly, if a thread does an in-line step over an exec syscall
      instruction, nothing clears the in-line step over info when the event is
      handled.  So it the in-line step over info stays there indefinitely, and
      things hang because we can never start another step over.  To fix this,
      I added a call to clear_step_over_info in infrun_inferior_execd.
      
      Add a test with a program with two threads that does an exec.  The test
      includes the following axes:
      
      - whether it's the leader thread or the other thread that does the exec.
      
      - whether the exec'r and exec'd program have different text segment
        addresses.  This is to hopefully catch cases where the displaced
        stepping info doesn't get reset, and GDB later tries to restore bytes
        of the old address space in the new address space.  If the mapped
        addresses are different, we should get some memory error.   This
        happens without the patch applied:
      
        $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-leader-diff-text-segs-true -ex "b main" -ex r -ex "b my_execve_syscall if 0"  -ex "set displaced-stepping on"
        ...
        Breakpoint 1, main (argc=1, argv=0x7fffffffde38) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.threads/step-over-exec.c:69
        69        argv0 = argv[0];
        Breakpoint 2 at 0x60133a: file /home/simark/src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S, line 34.
        (gdb) c
        Continuing.
        [New Thread 0x7ffff7c62640 (LWP 1455423)]
        Leader going in exec.
        Exec-ing /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-leader-diff-text-segs-true-execd
        [Thread 0x7ffff7c62640 (LWP 1455423) exited]
        process 1455418 is executing new program: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-leader-diff-text-segs-true-execd
        Error in re-setting breakpoint 2: Function "my_execve_syscall" not defined.
        No unwaited-for children left.
        (gdb) n
        Single stepping until exit from function _start,
        which has no line number information.
        Cannot access memory at address 0x6010d2
        (gdb)
      
      - Whether displaced stepping is allowed or not, so that we end up
        testing both displaced stepping and in-line stepping on arches that do
        support displaced stepping (otherwise, it just tests in-line stepping
        twice I suppose)
      
      To be able to precisely put a breakpoint on the syscall instruction, I
      added a small assembly file (lib/my-syscalls.S) that contains minimal
      Linux syscall wrappers.  I prefer that to the strategy used in
      gdb.base/step-over-syscall.exp, which is to stepi into the glibc wrapper
      until we find something that looks like a syscall instruction, I find
      that more predictable.
      
      gdb/ChangeLog:
      
      	* infrun.c (infrun_inferior_execd): New function.
      	(_initialize_infrun): Attach inferior_execd observer.
      
      gdb/testsuite/ChangeLog:
      
      	* gdb.threads/step-over-exec.exp: New.
      	* gdb.threads/step-over-exec.c: New.
      	* gdb.threads/step-over-exec-execd.c: New.
      	* lib/my-syscalls.S: New.
      	* lib/my-syscalls.h: New.
      
      Change-Id: I1bbc8538e683f53af5b980091849086f4fec5ff9
      3b7a962d
    • Simon Marchi's avatar
      gdb: add inferior_execd observable · 42a4fec5
      Simon Marchi authored
      I want to add another action (clearing displaced stepping state) that
      happens when an inferior execs.  I think it would be cleaner to have an
      observer for this event, rather than have infrun know about each other
      sub-component.
      
      Replace the calls to solib_create_inferior_hook and
      jit_inferior_created_hook in follow_exec by observers.
      
      gdb/ChangeLog:
      
      	* observable.h (inferior_execd): Declare new observable.
      	* observable.c (inferior_execd): Declare new observable.
      	* infrun.c (follow_exec): Notify inferior_execd observer.
      	* jit.c (jit_inferior_created_hook): Make static.
      	(_initialize_jit): Register inferior_execd observer.
      	* jit.h (jit_inferior_created_hook): Remove declaration.
      	* solib.c (_initialize_solib): Register inferior_execd observer.
      
      Change-Id: I000cce00094e23baa67df693d912646b6ae38e44
      42a4fec5
    • Tom de Vries's avatar
      [gdb] Fix heap-buffer-overflow in completion_tracker::build_completion_result · aafdfb4e
      Tom de Vries authored
      When building gdb with address sanitizer and running test-case
      gdb.base/completion.exp, we run into:
      ...
      ==5743==ERROR: AddressSanitizer: heap-buffer-overflow on address \
        0x60200025c02f at pc 0x000000cd9d64 bp 0x7fff3297da30 sp 0x7fff3297da28
      READ of size 1 at 0x60200025c02f thread T0
          #0 0xcd9d63 in completion_tracker::build_completion_result(char const*, \
                           int, int) gdb/completer.c:2258
        ...
      0x60200025c02f is located 1 bytes to the left of 1-byte region \
        [0x60200025c030,0x60200025c031)
      ...
      
      This can be reproduced using just:
      ...
      $ gdb
      (gdb) p/d[TAB]
      ...
      
      The problem is in this code in completion_tracker::build_completion_result:
      ...
            bool completion_suppress_append
              = (suppress_append_ws ()
                 || match_list[0][strlen (match_list[0]) - 1] == ' ');
      ...
      If strlen (match_list[0]) == 0, then we access match_list[0][-1].
      
      Fix this by testing if the memory access is in bounds before doing the memory
      access.
      
      Tested on x86_64-linux.
      
      gdb/ChangeLog:
      
      2020-12-04  Tom de Vries  <tdevries@suse.de>
      
      	PR gdb/27003
      	* completer.c (completion_tracker::build_completion_result): Don't
      	access match_list[0][-1].
      aafdfb4e
    • Tom Tromey's avatar
      Remove redundant typedefs · f99b5177
      Tom Tromey authored
      I was inspired by this patch of Simon's:
      
      https://sourceware.org/pipermail/gdb-patches/2020-November/173522.html
      
      ... to remove other typedefs that are no longer necessary now that gdb
      uses C++.
      
      I didn't remove absolutely every one -- I didn't touch the tdep files.
      However, I removed many of them.  In some cases, I removed an existing
      different struct tag.
      
      2020-12-04  Tom Tromey  <tromey@adacore.com>
      
      	* linespec.c (struct linespec_token): Rename; remove typedef.
      	* guile/scm-block.c (struct block_smob): Remove typedef.
      	(struct block_syms_progress_smob): Likewise.
      	* guile/scm-symbol.c (struct symbol_smob): Remove typedef.
      	* guile/scm-symtab.c (symtab_smob): Remove typedef.
      	(struct sal_smob): Remove typedef.
      	* guile/scm-param.c (struct param_smob): Remove typedef.
      	* guile/scm-progspace.c (struct pspace_smob): Rename.
      	* guile/scm-objfile.c (struct objfile_smob): Rename.
      	* guile/scm-iterator.c (struct iterator_smob): Rename.
      	* guile/scm-frame.c (struct frame_smob): Rename.
      	* guile/scm-arch.c (struct arch_smob): Rename.
      	* guile/scm-type.c (struct field_smob): Remove typedef.
      	(struct type_smob): Rename.
      	* guile/scm-cmd.c (struct command_smob): Remove typedef.
      	* guile/scm-ports.c (struct ioscm_memory_port): Remove typedef.
      	* guile/scm-value.c (struct value_smob): Remove typedef.
      	* guile/scm-lazy-string.c (lazy_string_smob): Remove typedef.
      	* guile/guile-internal.h (struct scheme_variable)
      	(struct scheme_function, struct scheme_integer_constant)
      	(struct gdb_smob, struct chained_gdb_smob)
      	(struct eqable_gdb_smob, arch_smob, frame_smob, iterator_smob)
      	(objfile_smob, pspace_smob, type_smob): Remove typedef.
      	* guile/scm-pretty-print.c (pretty_printer_smob): Remove typedef.
      	(struct pretty_printer_worker_smob): Remove typedef.
      	* guile/scm-exception.c (struct exception_smob): Remove typedef.
      	* python/py-block.c (struct block_object): Remove typedef.
      	(block_syms_iterator_object): Update.
      	(set_block): Update.
      	(block_syms_iterator_object): Remove typedef.
      	* python/py-inferior.c (struct membuf_object): Remove typedef.
      	* python/py-symtab.c (struct symtab_object): Remove typedef.
      	(set_symtab): Update.
      	(sal_object): Remove typedef.
      	(set_sal): Update.
      	* python/py-frame.c (frame_object): Remove typedef.
      	* python/py-record-btrace.c (struct btpy_list_object): Remove
      	typedef.
      	* python/py-arch.c (struct arch_object): Remove typedef.
      	* python/py-linetable.c (struct linetable_entry_object)
      	(linetable_object, struct ltpy_iterator_object): Remove typedef.
      	* python/py-events.h (eventregistry_object): Remove typedef.
      	(struct events_object): Remove typedef.
      	* python/python-internal.h (gdbpy_breakpoint_object): Remove
      	typedef.
      	(thread_object): Remove typedef.
      	* python/py-progspace.c (pspace_object): Remove typedef.
      	* python/py-value.c (struct value_object): Remove typedef.
      	* python/py-record.h (recpy_record_object): Remove typedef.
      	(struct recpy_element_object): Remove typedef.
      	* python/py-lazy-string.c (lazy_string_object): Remove typedef.
      	* python/py-objfile.c (objfile_object): Remove typedef.
      	* python/py-cmd.c (struct cmdpy_object): Remove typedef.
      	* python/py-type.c (type_object): Remove typedef.
      	(typy_iterator_object): Update.
      	(set_type): Update.
      	(field_object): Remove typedef.
      	(typy_iterator_object): Remove typedef.
      	* python/py-registers.c (register_descriptor_iterator_object):
      	Remove typedef.
      	(struct register_descriptor_object)
      	(struct reggroup_iterator_object, struct reggroup_object): Remove
      	typedef.
      	* python/py-record.c (recpy_gap_object): Remove typedef.
      	* python/py-symbol.c (symbol_object): Remove typedef.
      	(set_symbol): Update.
      	* python/py-event.h (event_object): Remove typedef.
      	* python/py-param.c (parmpy_object): Remove typedef.
      	* python/py-instruction.c (struct py_insn_obj): Remove typedef.
      	* python/py-unwind.c (struct pending_frame_object): Remove typedef.
      	(unwind_info_object, struct cached_frame_info): Likewise.
      f99b5177
    • Simon Marchi's avatar
      gdb/testsuite: make declare_labels use better default label names · e633b117
      Simon Marchi authored
      When using the single-element form of argument to declare_labels, the
      generated label (in the assembly file) is of the format ".LlabelN",
      where N is a number.
      
      I propose making it use the name of the label by default.  Calling:
      
          declare_labels foo
      
      will generate the ".LfooN" in the assembly file (again, where N is a
      number).  When debugging the output of the DWARF assembler, it makes it
      easier to map labels to the source.  Also, when defining the same label
      twice by mistake in the Tcl code (like I d id), it's easier to track the
      error from the message to the root cause:
      
          -/home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/implptrpiece/implptrpiece-dw.S:62: Error: symbol `.Llabel5' is already defined
          +/home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/implptrpiece/implptrpiece-dw.S:62: Error: symbol `.Lvar_label5' is already defined
      
      This doesn't change anything for the test cases, it just makes the
      assembly output a bit nicer.
      
      gdb/testsuite/ChangeLog:
      
      	* lib/dwarf.exp (declare_labels): Use name as text if text is
      	not provided.
      
      Change-Id: I63856c1fa6390498fd5b9d66f471f817ff0a465c
      e633b117
    • Bernd Edlinger's avatar
      Fix building gdb release from tar file without makeinfo · ab954e4a
      Bernd Edlinger authored
      Add GDBvn.texi and version.subst to the release tar file,
      so the gdb.info does not need makeinfo.
      
      This avoids the need for makeinfo to be available.
      
      2020-12-04  Bernd Edlinger  <bernd.edlinger@hotmail.de>
      
      	* Makefile.in: Delete GDBvn.texi and version.subst only in
      	the maintainer-clean target.
      ab954e4a
    • Shahab Vahedi's avatar
      Update gdb/ChangeLog to reflect the PR for a bug fix · 10806efd
      Shahab Vahedi authored
      This is just an update in the gdb/ChangeLog to reflect a newly
      created PR [27015] for a bugfix commit:
      
      10c19fad  arc: Write correct "eret" value during register collection
      10806efd
    • Tom Tromey's avatar
      Constify value_internal_function_name · 91f87213
      Tom Tromey authored
      I noticed that value_internal_function_name should have a const return
      type.  This patch makes this change.
      
      gdb/ChangeLog
      2020-12-04  Tom Tromey  <tromey@adacore.com>
      
      	* value.c (value_internal_function_name): Make return type const.
      	* value.h (value_internal_function_name): Make return type const.
      91f87213
    • Luis Machado's avatar
      Fix shifting of negative value · 5382f971
      Luis Machado authored
      When UBSan is enabled, I noticed runtime errors complaining of shifting
      of negative numbers.
      
      This patch fixes this by reusing existing macros from the ARM port.
      
      It also removes unused macros from AArch64's port.
      
      gdb/ChangeLog:
      
      2020-12-04  Luis Machado  <luis.machado@linaro.org>
      
      	* aarch64-tdep.c (submask, bit, bits): Remove.
      	* arch/aarch64-insn.c (extract_signed_bitfield): Remove.
      	(aarch64_decode_adr, aarch64_decode_b aarch64_decode_bcond)
      	(aarch64_decode_cb, aarch64_decode_tb)
      	(aarch64_decode_ldr_literal): Use sbits to extract a signed
      	immediate.
      	* arch/aarch64-insn.h (submask, bits, bit, sbits): New macros.
      5382f971
    • Tom de Vries's avatar
      [gdb/testsuite] Make gdb.arch/amd64-gs_base.exp unsupported for i386 · 67748e0f
      Tom de Vries authored
      With target board unix/-m32 I run into:
      ...
      (gdb) print /x $fs_base^M
      $1 = void^M
      (gdb) FAIL: gdb.arch/amd64-gs_base.exp: print fs_base
      ...
      
      The problem is that the fs_base register is not supported for i386.
      
      Fix this by making the test unsupported if fs_base/gs_base don't show up in
      info register sys output.
      
      Tested on x86_64-linux.
      
      gdb/testsuite/ChangeLog:
      
      2020-12-04  Tom de Vries  <tdevries@suse.de>
      
      	PR testsuite/26990
      	* gdb.arch/amd64-gs_base.exp: Handle -m32 where fs_base and gs_base
      	are unsupported.
      67748e0f
    • Tom de Vries's avatar
      [gdb/tdep] Handle static field in i386_16_byte_align_p · b6a6aa07
      Tom de Vries authored
      When running test-case on gdb.cp/many-args.exp with target board unix/-m32, I
      run into:
      ...
      (gdb) p check_val (ref_val, ref_val, ... , ref_val, ref_val)^M
      $1 = false^M
      (gdb) FAIL: gdb.cp/many-args.exp: check passing many structures
      ...
      
      The test source contains struct ss:
      ...
      typedef int v4si __attribute__ ((vector_size (16)));
      
      struct ss
      {
        static v4si static_field;
        unsigned char aa;
      };
      ...
      and i386_16_byte_align_p returns true for this type.
      
      Fix this by skipping static fields in i386_16_byte_align_p.
      
      Tested on x86_64-linux.
      
      gdb/ChangeLog:
      
      2020-12-04  Tom de Vries  <tdevries@suse.de>
      
      	PR tdep/27007
      	* i386-tdep.c (i386_16_byte_align_p): Skip static fields.
      b6a6aa07
    • Tom de Vries's avatar
      [gdb/testsuite] Fix control-flow in gdb.reverse/insn-reverse.exp · a8d13675
      Tom de Vries authored
      In gdb.reverse/insn-reverse.exp, we have loop containing a call to
      gdb_test_multiple, which itself contains a break:
      ...
        for {} {$count < 500} {incr count} {
          ...
          gdb_test_multiple "x/i \$pc" "" {
            ...
            break
          }
      ...
      
      On SLE-11 with:
      ...
      $ runtest --version
      Expect version is       5.44.1.11
      Tcl version is          8.5
      Framework version is    1.4.4
      ...
      the break doesn't seem to have the effect of breaking out of the loop.
      
      The break does have the effect of terminating evaluation of the expect clause,
      which means we don't set insn_array, after which we run into:
      ...
      ERROR: tcl error sourcing src/gdb/testsuite/gdb.reverse/insn-reverse.exp.
      ERROR: can't read "insn_array(5)": no such element in array
      ...
      
      gdb/testsuite/ChangeLog:
      
      2020-12-04  Tom de Vries  <tdevries@suse.de>
      
      	* gdb.reverse/insn-reverse.exp: Don't break inside gdb_test_multiple
      	clause.
      a8d13675
    • Tom de Vries's avatar
      [gdb/testsuite] Fix count usage in gdb.reverse/insn-reverse.exp · f17727b3
      Tom de Vries authored
      Consider the test-case gdb.reverse/insn-reverse.exp.
      
      After the loop setting count, the valid entries in various arrays range from 0
      to $count - 1 inclusive.
      
      Then $count is decremented:
      ...
             incr count -1
      ...
      after which the valid entries range from 0 to $count inclusive.
      
      The first subsequent loop handles that properly:
      ...
             for {set i $count} {$i >= 0} {incr i -1} {
      ...
      but the following loop does not, because it treats $count as exclusive bound:
      ...
      	for {set i 0} {$i < $count} {incr i} {
      ...
      
      Fix this by removing the incr, and using $count - 1 as starting value in the
      first loop.
      
      gdb/testsuite/ChangeLog:
      
      2020-12-04  Tom de Vries  <tdevries@suse.de>
      
      	* gdb.reverse/insn-reverse.exp: Fix count handling.
      f17727b3
    • Tom de Vries's avatar
      [gdb/testsuite] Fix gdb.reverse/insn-reverse-x86.c for -m32 · a1499830
      Tom de Vries authored
      When running test-case gdb.reverse/insn-reverse.exp with target board
      unix/-m32, we get:
      ...
      spawn -ignore SIGHUP gcc -fno-stack-protector -fdiagnostics-color=never \
        -c -g -m32 -o insn-reverse0.o insn-reverse.c^M
      insn-reverse-x86.c: Assembler messages:^M
      insn-reverse-x86.c:88: Error: bad register name `%r8w'^M
      ....
      
      Fix this by guarding x86_64 assembly in insn-reverse-x86.c with #ifdef
      __x86_64__.
      
      Tested on x86_64-linux, with native and unix/-m32.
      
      gdb/testsuite/ChangeLog:
      
      2020-12-04  Tom de Vries  <tdevries@suse.de>
      
      	* gdb.reverse/insn-reverse-x86.c: Guard x86_64 assembly with #ifdef
      	__x86_64__.
      a1499830
    • Tom de Vries's avatar
      [gdb/testsuite] Handle SIGILL in gdb.reverse/insn-reverse.exp · 9c027c2f
      Tom de Vries authored
      Consider test-case gdb.reverse/insn-reverse.exp.
      
      It runs a number of subtests, dependent on the architecture, f.i. for
      x86_64 it runs subtests rdrand and rdseed.
      
      For each subtest, it checks whether the subtest is supported and otherwise
      bails out of that subtest.
      
      However, there may be a problem with the support test or the information it
      relies on, and if it states that a subtest is supported while it is actually
      not, we may run into a SIGILL, as f.i. described in PR21166, which results in
      tcl errors like this:
      ...
      ERROR: tcl error sourcing src/gdb/testsuite/gdb.reverse/insn-reverse.exp.
      ERROR: can't read "insn_array(5)": no such element in array
      ...
      
      We can emulate this by inserting a sigfpe in function rdrand in
      insn-reverse-x86.c, like this:
      ...
        volatile int a = 0; volatile int b = 1; volatile int c = b / a;
      ...
      
      The problem is that the loop in the test-case attempts to stepi over of all
      insn in rdrand, but because of the signal it will never get to the last insn.
      
      Handle this by detecting that the stepi made no progress, and bailing out of
      the loop.
      
      Furthermore, make running of the subtests independent, such that a SIGILL in
      subtest rdrand does not affect running of subtest rdseed.
      
      Tested on x86_64-linux.
      
      gdb/testsuite/ChangeLog:
      
      2020-12-04  Tom de Vries  <tdevries@suse.de>
      
      	* gdb.reverse/insn-reverse.c (test_nr): New var.
      	(usage, parse_args): New function.
      	(main): Call parse_args.  Only run test for test_nr.
      	* gdb.reverse/insn-reverse.exp: Detect lack of progress in stepi loop
      	and bail out.  Run subtests individually, using an inferior arg
      	specifying the subtest.
      9c027c2f
    • Andreas Krebbel's avatar
      IBM Z: Add risbgz and risbgnz extended mnemonics · c524d11e
      Andreas Krebbel authored
      These two extended mnemonics are documented in the Principles of
      Operations manual but currently not supported by Binutils. They
      provide aliases for already supported instructions with the zero flag
      being set.  The flag otherwise is mingled into one of the immediate
      operands what makes asm code much harder to read.
      
      opcodes/
      
      	* s390-opc.txt: Add risbgz and risbgnz.
      	* s390-opc.c (U6_26): New operand type.
      	(INSTR_RIE_RRUUU2, MASK_RIE_RRUUU2): New instruction format and
      	mask.
      
      gas/
      
      	* testsuite/gas/s390/zarch-z10.s: Add tests for risbgz.
      	* testsuite/gas/s390/zarch-z10.d: Add regexp for risbgz.
      	* testsuite/gas/s390/zarch-zEC12.s: Add tests for risbgnz.
      	* testsuite/gas/s390/zarch-zEC12.d: Add regexp for risbgnz.
      c524d11e
    • Alan Modra's avatar
      asan: readelf: memory leaks · 288f0ba2
      Alan Modra authored
      This tidies some code used by readelf, hopefully fixing some
      intermittent oss-fuzz bug reports that likely could only be reproduced
      by feeding readelf two or more object files on the command line.  The
      second and subsequent file may see non-zero state in .bss variables,
      and non-initial values in .data variables.  This patch fixes some of
      those, and moves some .data variables to .rodata.
      
      	* dwarf.c (frame_display_row): Do without static variable "sloc".
      	(cu_tu_indexes_read): Move to file scope.
      	(free_debug_memory): Reset it here, along with level_type_signed.
      	Free and clear a number of other static variables.
      	* readelf.c (arm_attr_public_tag <table>): Constify, updating..
      	(arm_attr_tag_*): ..all these uses.
      	(process_mips_specific): Free "rels" on error path.
      288f0ba2
    • Alan Modra's avatar
      PR26978, Inconsistency for strong foo@v1 and weak foo@@v1 · 726d7d1e
      Alan Modra authored
      Prior to this patch
        ld -shared --version-script=pr26979.ver pr26978a.o pr26978b.o
      results in
        ld: pr26978b.o: in function `foo_v1':
        (.text+0x0): multiple definition of `foo@v1'
        ld: pr26978b.o:(*IND*+0x0): multiple definition of `foo'
      while
        ld -shared --version-script=pr26979.ver pr26978b.o pr26978a.o
      results in no error, but some odd dynamic symbols.
        ... 0 NOTYPE  GLOBAL DEFAULT    7 foo@v1
        ... 0 NOTYPE  WEAK   DEFAULT    7 foo@@v1
      
      When linking an undecorated reference to foo against such a shared
      library, ld complains about multiple definitions of foo@v1 while gold
      creates a dynamic reference to foo@v1.  That results in foo@v1 being
      used at runtime.
      
      While we could error in both cases, it is reasonable to say foo@v1 and
      foo@@v1 are in fact the same symbol.  (Same name, same version.  The
      only real difference is that foo@@v1 satisfies a reference to plain
      foo, while foo@v1 does not.)  Just as merging a weak undecorated sym
      with a strong sym results in the strong sym prevailing, so should the
      strong foo@v1 prevail.  And since there is a definition that satisfies
      plain foo, the foo@@v1 variety of dynamic symbol should be emitted at
      the foo@v1 value.  That makes the testcase that currently links
      continue to produce a shared library, and that shared library can now
      be used by both ld and gold with the same runtime behaviour as when
      using gold with the odd dynamic symbol library.
      
      bfd/
      	PR 26978
      	* elflink.c (_bfd_elf_add_default_symbol): Handle the case where
      	a new weak sym@@ver should be overridden by an existing sym@ver.
      	(elf_link_add_object_symbols): Don't _bfd_elf_add_default_symbol
      	for a new weak sym@ver when sym@@ver already exists.
      	* linker.c (link_action): Choose MIND for previous indirect,
      	current def, rather than MDEF.
      	(_bfd_generic_link_add_one_symbol <MIND>): Handle redefinition of
      	weak indirect symbol.
      ld/
      	* testsuite/ld-elf/pr26978a.d,
      	* testsuite/ld-elf/pr26978a.s,
      	* testsuite/ld-elf/pr26978b.d,
      	* testsuite/ld-elf/pr26978b.s: New tests.
      726d7d1e
    • GDB Administrator's avatar
      Automatic date update in version.in · 099ee20a
      GDB Administrator authored
      099ee20a
  2. 03 Dec, 2020 5 commits
    • Simon Marchi's avatar
      gdb: fix logic of find_comp_unit and set_comp_unit · 0bc2e38d
      Simon Marchi authored
      The logic in find_comp_unit and set_comp_unit is reversed.  When the BFD
      requires relocation, we want to put the comp_unit structure in the
      map where the comp_unit objects are not shared, that is the one indexed
      by objfile.  If the BFD does not require relocation, then, we can share
      a single comp_unit structure for all users of that BFD, so we want to
      put it in the BFD-indexed map.  The comments on top of
      dwarf2_frame_bfd_data and dwarf2_frame_objfile_data make that clear.
      
      Fix it by swapping the two in find_comp_unit and set_comp_unit.
      
      I don't have a test for this, because I don't see how to write one in a
      reasonable amount of time.
      
      gdb/ChangeLog:
      
      	PR gdb/26876
      	* dwarf2/frame.c (find_comp_unit, set_comp_unit): Reverse use of
      	dwarf2_frame_bfd_data and dwarf2_frame_objfile_data.
      
      Change-Id: I80c1ee7ad8425fa4947de65b170973d05f5a52ec
      0bc2e38d
    • Andreas Krebbel's avatar
      IBM Z: Add support for HLASM extended mnemonics · b10b530a
      Andreas Krebbel authored
      Add extended mnemonics used in the HLASM assembler.  All of them are
      just aliases for instructions we already support and help when
      assembling code which was written for the HLASM assembler.
      
      The HLASM mnemonics are documented here:
      https://www.ibm.com/support/knowledgecenter/SSENW6_1.6.0/com.ibm.hlasm.v1r6.asm/asmr1023.pdf
      
      See the 'Branching with extended mnemonic codes' chapter.
      
      objdump will still print the existing mnemonics with the exception of
      relative nop branches (i.e. conditional branches with an empty
      condition code mask).  Now we have jnop and jgnop which will be used
      by objdump when possible.
      
      The same change have been applied to the LLVM assembler:
      https://reviews.llvm.org/D92185
      
      opcodes/
      
      	* s390-opc.txt: Add extended mnemonics.
      
      gas/
      
      	* testsuite/gas/s390/esa-g5.s: Test new extended mnemonics.
      	* testsuite/gas/s390/esa-g5.d: Likewise.
      	* testsuite/gas/s390/esa-z900.s: Likewise.
      	* testsuite/gas/s390/esa-z900.d: Likewise.
      	* testsuite/gas/s390/zarch-z900.s: Likewise.
      	* testsuite/gas/s390/zarch-z900.d: Likewise.
      
      ld/
      
      	* testsuite/ld-s390/tlsbin_64.dd: The newly added jgnop mnemonic
      	replaces long relative branches with empty condition code mask.
      b10b530a
    • Maciej W. Rozycki's avatar
      VAX/LD/testsuite: Wrap excessively long lines · 9a5c1ed8
      Maciej W. Rozycki authored
      A couple of lines in the vax-elf.exp test script exceed 80 characters;
      wrap them.
      
      	ld/
      	* testsuite/ld-vax-elf/vax-elf.exp: Wrap excessively long lines
      	throughout.
      9a5c1ed8
    • Alan Modra's avatar
      [GOLD] PR26936 test · c6162010
      Alan Modra authored
      Fails if you configure with --disable-x86-used-note.  Fix that.
      
      	* testsuite/Makefile.am (pr26936a.o): Pass -mx86-used-note=yes.
      	(pr26936b.o, pr26936c.o, pr26936d.o): Likewise.
      	* testsuite/Makefile.in: Regenerate.
      c6162010
    • GDB Administrator's avatar
      Automatic date update in version.in · 317c8bbc
      GDB Administrator authored
      317c8bbc
  3. 02 Dec, 2020 9 commits
    • Hans-Peter Nilsson's avatar
      testsuite/ld-elf/pr26936.d: Pass -W. · 5f410aa5
      Hans-Peter Nilsson authored
      Required for the expected "CU:" to be emitted for long
      source-paths.  See binutils/dwarf.c:
      
       if (do_wide || strlen (directory) < 76)
         printf (_("CU: %s/%s:\n"), directory, file_table[0].name);
       else
         printf ("%s:\n", file_table[0].name);
      5f410aa5
    • Andrew Burgess's avatar
      gdb/riscv: rewrite target description validation, add rv32e support · 25428040
      Andrew Burgess authored
      This commit started as adding rv32e support to gdb.  The rv32e
      architecture is a cut-down rv32i, it only has 16 x-registers compared
      to the usual 32, and an rv32e target should not have any floating
      point registers.
      
      In order to add this I needed to adjust the target description
      validation checks that are performed from riscv_gdbarch_init, and I
      finally got fed up with the current scheme of doing these checks and
      rewrote this code.
      
      Unfortunately the rv32e changes are currently mixed in with the
      rewrite of the validation scheme.  I could split these apart if anyone
      is really interested in seeing these two ideas as separate patches.
      
      The main idea behind this change is that where previously I tried to
      have a purely data driven approach, a set of tables one for each
      expected feature, and then a single generic function that would
      validate a feature given a table, I have created a new class for each
      feature.  Each class has its own check member function which allows
      the logic for how to check each feature to be different.  I think the
      new scheme is much easier to follow.
      
      There are some other changes that I made to the validation code as
      part of this commit.
      
      I've relaxed some of the checks related to the floating point CSRs.
      Previously the 3 CSRs fflags, frm, and fcsr all had to be present in
      either the fpu feature or the csr feature.  This requirement is now
      relaxed, if the CSRs are not present then gdb will not reject the
      target description.  My thinking here is that there's no gdb
      functionality that specifically requires these registers, and so, if a
      target offers a description without these registers nothing else in
      gdb should stop working.
      
      And as part of the rv32e support targets now only have to provide the
      first 16 x-registers and $pc.  The second half of the x-registers (x16
      -> x31) are now optional.
      
      gdb/ChangeLog:
      
      	* arch/riscv.c: Include 'rv32e-xregs.c'.
      	(riscv_create_target_description): Update to handle rv32e.
      	* arch/riscv.h (struct riscv_gdbarch_features) <embedded>: New
      	member variable.
      	<operator==>: Update to account for new field.
      	<hash>: Likewise.
      	* features/Makefile (FEATURE_XMLFILES): Add riscv/rv32e-xregs.xml.
      	* features/riscv/rv32e-xregs.c: Generated.
      	* features/riscv/rv32e-xregs.xml: New file.
      	* riscv-tdep.c (riscv_debug_breakpoints): Move from later in the
      	file.
      	(riscv_debug_infcall): Likewise.
      	(riscv_debug_unwinder): Likewise.
      	(riscv_debug_gdbarch): Likewise.
      	(enum riscv_register_required_status): Delete.
      	(struct riscv_register_feature): Add constructor, delete default
      	constructor, copy, and assign constructors.
      	(struct riscv_register_feature::register_info) <required>: Delete.
      	<check>: Update comment and arguments.
      	(struct riscv_register_feature) <name>: Change to member function.
      	<prefer_first_name>: Delete.
      	<tdesc_feature>: New member function.
      	<registers>: Rename to...
      	<m_registers>: ...this.
      	<m_feature_name>: New member variable.
      	(riscv_register_feature::register_info::check): Update arguments.
      	(riscv_xreg_feature): Rewrite as class, create a single static
      	instance of the class.
      	(riscv_freg_feature): Likewise.
      	(riscv_virtual_feature): Likewise.
      	(riscv_csr_feature): Likewise.
      	(riscv_create_csr_aliases): Has become a member function inside
      	riscv_csr_feature class.
      	(riscv_abi_embedded): New function definition.
      	(riscv_register_name): Adjust to use new feature objects.
      	(struct riscv_call_info) <riscv_call_info>: Check for rv32e abi,
      	and adjust available argument registers.
      	(riscv_features_from_gdbarch_info): Check for EF_RISCV_RVE flag.
      	(riscv_check_tdesc_feature): Delete.
      	(riscv_tdesc_unknown_reg): Adjust to use new feature objects.
      	(riscv_gdbarch_init): Delete target description checking code, and
      	instead call to the new feature objects to perform the checks.
      	Reorder handling of no abi information case, allows small code
      	simplification.
      	(_initialize_riscv_tdep): Remove call, this is now done in the
      	riscv_csr_feature constructor.
      	* riscv-tdep.h (riscv_abi_embedded): Declare.
      25428040
    • Andrew Burgess's avatar
      gdb/riscv: remove csr aliases created with DECLARE_CSR_ALIAS · 533b2ae0
      Andrew Burgess authored
      In this commit:
      
        commit 767a879e
        Date:   Tue Jun 9 17:38:30 2020 +0100
      
            gdb/riscv: Improved register alias name creation
      
      RISC-V GDB was changed to make use of the DECLARE_CSR_ALIAS macro to
      define register aliases for some CSRs.  Actually, only one alias was
      created 'dscratch' as an alias for 'dscratch0'.  All of the other
      DECLARE_CSR_ALIAS lines (from include/opcode/riscv-opc.h) were
      filtered out.
      
      In this commit:
      
        commit 08ccfccf
        Date:   Mon Jun 8 10:54:53 2020 +0800
      
            RISC-V: Support debug and float CSR as the unprivileged ones.
      
      Changes were made to include/opcode/riscv-opc.h so that GDB no longer
      created even the dscratch alias.
      
      This caused a test failure in gdb.arch/riscv-tdesc-regs.exp.
      
      In looking at how to address this failure I think that the best
      strategy is, for now at least, to just remove the code that tries to
      create aliases with DECLARE_CSR_ALIAS.
      
      My thoughts are that:
      
        1. At least some of the aliases are for CSRs where the register now
        has a completely different use.  Being able to reference the CSR
        using a completely inappropriate name just seems confusing.  This
        was solved by the filtering added in the first commit referenced
        above.  But we certainly don't want to blindly add all aliases.
      
        2. Names presented in a target description are always honoured, so
        if a user has a legacy target then they should just start sending a
        target description with their legacy register names in, this problem
        is then solved.
      
        3. It's easy enough to figure out which CSRs a target has with the
        info registers command, so missing an alias shouldn't be a big
        issue.
      
        4.  Allowing users to use names for registers that differ from the
        names the target announces doesn't feel like a critical feature.  If
        in the future targets want multiple names for a register then maybe
        we could/should extend target descriptions to allow the target to
        send aliases as well as the primary name.... but that can wait for
        another day.
      
      So in this commit I remove the use of DECLARE_CSR_ALIAS, and remove
      the test that was failing.
      
      gdb/ChangeLog:
      
      	* riscv-tdep.c (riscv_create_csr_aliases): Remove use of
      	DECLARE_CSR_ALIAS.
      
      gdb/testsuite/ChangeLog:
      
      	* gdb.arch/riscv-tdesc-regs.exp: Remove unwanted test.
      533b2ae0
    • Andrew Burgess's avatar
      gdb/riscv: place unknown csrs into the correct register groups · e4502042
      Andrew Burgess authored
      Unknown riscv CSRs should not be in the 'general' group, but should be
      in the system and csr register groups.
      
      To see this in action connect to QEMU, this target advertises two
      registers dscratch and mucounteren which are unknown to GDB (these are
      legacy CSRs).  Before this commit these registers would show up in the
      output of:
      
        (gdb) info registers
        ....
        dscratch       Could not fetch register "dscratch"; remote failure reply 'E14'
        mucounteren    Could not fetch register "mucounteren"; remote failure reply 'E14'
      
      Ignore the errors, this is just a QEMU annoyance, it advertises these
      CSRs, but doesn't actually let GDB read them.  These registers don't
      show up in the output of either:
      
        (gdb) info registers csr
        (gdb) info registers system
      
      After this commit this situation is reveresed, which makes more sense
      to me.
      
      gdb/ChangeLog:
      
      	* riscv-tdep.c (riscv_is_unknown_csr): New function,
      	implementation moved from riscv_register_reggroup_p.
      	(riscv_register_reggroup_p): Update group handling for unknown
      	CSRs.
      
      gdb/testsuite/ChangeLog:
      
      	* gdb.arch/riscv-tdesc-regs.exp (get_expected_result): New proc,
      	update test to use this.
      e4502042
    • Enze Li's avatar
      Add gnu global outputs to .gitignore · 7ddfb1a8
      Enze Li authored
      GNU Global outputs can be safely ignored.
      
      ChangeLog:
      
      2020-12-02  Enze Li  <lienze2010@hotmail.com>
      
      	* .gitignore: Add gnu global outputs.
      
      Change-Id: I04ce68ab3279426195793adb56f834a34ee72ea2
      7ddfb1a8
    • Simon Marchi's avatar
      Sync .gitignore with gcc · 12bf6525
      Simon Marchi authored
      Bring in a few lines that are in gcc's .gitignore but not binutils-gdb's
      .gitignore.
      
      ChangeLog:
      
      	* .gitignore: Sync with gcc.
      
      Change-Id: I8900ddfbb5ab8cce6236e1905fdbb52fb4c291e2
      12bf6525
    • Sergio Durigan Junior's avatar
      Search for DWZ files in debug-file-directories as well · 2bf3b79d
      Sergio Durigan Junior authored
      When Debian (and Ubuntu) builds its binaries, it (still) doesn't use
      dwz's "--relative" option.  This causes their debuginfo files to
      carry a .gnu_debugaltlink section containing a full pathname to the
      DWZ alt debug file, like this:
      
        $ readelf -wk /usr/bin/cat
        Contents of the .gnu_debugaltlink section:
      
          Separate debug info file: /usr/lib/debug/.dwz/x86_64-linux-gnu/coreutils.debug
          Build-ID (0x14 bytes):
         ee 76 5d 71 97 37 ce 46 99 44 32 bb e8 a9 1a ef 99 96 88 db
      
        Contents of the .gnu_debuglink section:
      
          Separate debug info file: 06d3bee37b8c7e67b31cb2689cb351102ae73b.debug
          CRC value: 0x53267655
      
      This usually works OK, because most of the debuginfo files installed
      via apt will be present in /usr/lib/debug anyway.  However, imagine
      the following scenario:
      
      - You are using /usr/bin/cat, it crashes on you and generates a
        corefile.
      
      - You don't want/need to "apt install" the debuginfo file for
        coreutils from the repositories.  Instead, you already have the
        debuginfo files in a separate directory (e.g., $HOME/dbgsym).
      
      - You start GDB and "set debug-file-directory $HOME/dbgsym/usr/lib/debug".
        You then get the following message:
      
        $ gdb -ex 'set debug-file-directory ./dbgsym/usr/lib/debug' -ex 'file /bin/cat' -ex 'core-file ./cat.core'
        GNU gdb (Ubuntu 10.1-0ubuntu1) 10.1
        ...
        Reading symbols from /bin/cat...
        Reading symbols from /home/sergio/gdb/dbgsym/usr/lib/debug/.build-id/bc/06d3bee37b8c7e67b31cb2689cb351102ae73b.debug...
        could not find '.gnu_debugaltlink' file for /home/sergio/gdb/dbgsym/usr/lib/debug/.build-id/bc/06d3bee37b8c7e67b31cb2689cb351102ae73b.debug
      
      This error happens because GDB is trying to locate the build-id
      link (inside /home/sergio/gdb/dbgsym/usr/lib/debug/.build-id) for the
      DWZ alt debug file, which doesn't exist.  Arguably, this is a problem
      with how dh_dwz works in Debian, and it's something I'm also planning
      to tackle.  But, back at the problem at hand.
      
      Besides not being able to find the build-id link in the directory
      mentioned above, GDB also tried to open the DWZ alt file using its
      filename.  The problem here is that, since we don't have the distro's
      debuginfo installed, it can't find anything under /usr/lib/debug that
      satisfies it.
      
      It occurred to me that a good way to workaround this problem is to
      actually try to locate the DWZ alt debug file inside the
      debug-file-directories (that were likely provided by the user).  So
      this is what the proposed patch does.
      
      The idea here is simple: get the filename extracted from the
      .gnu_debugaltlink section, and manipulate it in order to replace the
      initial part of the path (everything before "/.dwz/") by whatever
      debug-file-directories the user might have provided.
      
      I talked with Mark Wielaard and he agrees this is a sensible approach.
      In fact, apparently this is something that eu-readelf also does.
      
      I regtested this code, and no regressions were found.
      
      2020-12-01  Sergio Durigan Junior  <sergiodj@sergiodj.net>
      
      	* dwarf2/read.c (dwz_search_other_debugdirs): New function.
      	(dwarf2_get_dwz_file): Convert 'filename' to a
      	std::string.  Use dwz_search_other_debugdirs to search for DWZ
      	files in the debug-file-directories provided by the user as well.
      2bf3b79d
    • Tom Tromey's avatar
      Use new+delete for struct expression · 77bf7e99
      Tom Tromey authored
      In another series I'm working on, it is necessary to manage
      "struct expression" with new and delete.  Because the patch is
      straightforward and could be extracted, I've done so here.
      
      gdb/ChangeLog
      2020-12-01  Tom Tromey  <tom@tromey.com>
      
      	* parse.c (expr_builder::expr_builder): Initialize expout.
      	(expr_builder::release): Use expression::resize.
      	(expression::expression, expression::~expression)
      	(expression::resize): New methods.
      	(write_exp_elt): Use expression::resize.
      	(prefixify_expression): Update.
      	(increase_expout_size): Use expression::resize.
      	* expression.h (struct expression): Add constructor, destructor.
      	<resize>: New method.
      	(expression_up): Change type.
      77bf7e99
    • GDB Administrator's avatar
      Automatic date update in version.in · e89b3d52
      GDB Administrator authored
      e89b3d52
  4. 01 Dec, 2020 6 commits
    • Simon Marchi's avatar
      gdb/testsuite: fix indentation in gdb.threads/non-ldr-exc-1.exp · f55a9a37
      Simon Marchi authored
      gdb/testsuite/ChangeLog:
      
      	* gdb.threads/non-ldr-exc-1.exp: Fix indentation.
      
      Change-Id: I02ba8a518aae9cb67106d09bef92968a7078e91e
      f55a9a37
    • Simon Marchi's avatar
      gdb/testsuite: use foreach_with_prefix in gdb.threads/non-ldr-exc-*.exp · 0a6155a0
      Simon Marchi authored
      Replace the manual with_test_prefix in the do_test proc with using
      foreach_with_prefix at the top-level.  This helps reduce the indentation
      level of the code a bit, and makes the test names in sync with the
      variable names used in the code.
      
      gdb/testsuite/ChangeLog:
      
      	* gdb.threads/non-ldr-exc-1.exp: Use foreach_with_prefix.
      	(do_test): Don't use with_test_prefix.
      	* gdb.threads/non-ldr-exc-2.exp: Use foreach_with_prefix.
      	(do_test): Don't use with_test_prefix.
      	* gdb.threads/non-ldr-exc-3.exp: Use foreach_with_prefix.
      	(do_test): Don't use with_test_prefix.
      	* gdb.threads/non-ldr-exc-4.exp: Use foreach_with_prefix.
      	(do_test): Don't use with_test_prefix.
      
      Change-Id: I3af1df2eee1a8add427a67b6048bb6dede41cbeb
      0a6155a0
    • Rogerio Alves's avatar
      PowerPC remove 512 bytes region limit if 2nd DAWR is avaliable. · 539d71e8
      Rogerio Alves authored
      Power 10 introduces the 2nd DAWR (second watchpoint) and also removed
      a restriction that limit the watch region to 512 bytes.
      
      2020-11-08  Rogerio A. Cardoso  <rcardoso@linux.ibm.com>
      
      /gdb
      
      	* ppc-linux-nat.c: (PPC_DEBUG_FEATURE_DATA_BP_ARCH_31): New define.
      	(region_ok_for_hw_watchpoint): Check if 2nd DAWR is avaliable before
      	set region.
      539d71e8
    • Rogerio Alves's avatar
      Add missing ChangeLog entry. · 0ae45769
      Rogerio Alves authored
      0ae45769
    • Simon Marchi's avatar
      gdb/testsuite: fix comment in gdb.threads/non-ldr-exit.exp · 4d56d64a
      Simon Marchi authored
      Maybe there's something I don't understand in that test, but the comment
      seems wrong.  It checks what happens when the non-leader thread does an
      exit, not the leader.
      
      gdb/testsuite/ChangeLog:
      
      	* gdb.threads/non-ldr-exit.exp: Fix comment.
      
      Change-Id: I35c96a70c097fa9529737874f54f3f78036008a4
      4d56d64a
    • H.J. Lu's avatar
      arc: Enable -Ttext-segment · 3ed3c104
      H.J. Lu authored
      Define TEXT_START_ADDR and SHLIB_TEXT_START_ADDR with SEGMENT_START to
      enable -Ttext-segment.
      
      	PR ld/26970
      	* scripttempl/elfarc.sc (TEXT_START_ADDR): New.  Add SEGMENT_START.
      	(SHLIB_TEXT_START_ADDR): Likewise.
      3ed3c104