and though bugs are the bane of my existence, rest assured the wretched thing will get the best of care here

  1. 22 Nov, 2017 4 commits
    • Gary Benson's avatar
      linux: Add maintenance commands to test libthread_db · 66e8d8be
      Gary Benson authored
      This commit adds two new commands which may be used to test thread
      debugging libraries used by GDB:
      
        * "maint check libthread-db" tests the thread debugging library GDB
           is using for the current inferior.
      
        * "maint set/show check-libthread-db" selects whether libthread_db
           tests should be run automatically as libthread_db is auto-loaded.
           The default is to not run tests automatically.
      
      The test itself is a basic integrity check exercising all libthread_db
      functions used by GDB on GNU/Linux systems.  By extension this also
      exercises the proc_service functions provided by GDB that libthread_db
      uses.
      
      This functionality is useful for NPTL developers and libthread_db
      developers.  It could also prove useful investigating bugs reported
      against GDB where the thread debugging library or GDB's proc_service
      layer is suspect.
      
      gdb/ChangeLog:
      
      	* linux-thread-db.c (valprint.h): New include.
      	(struct check_thread_db_info): New structure.
      	(check_thread_db_on_load, tdb_testinfo): New static globals.
      	(check_thread_db, check_thread_db_callback): New functions.
      	(try_thread_db_load_1): Run integrity checks if requested.
      	(maintenance_check_libthread_db): New function.
      	(_initialize_thread_db): Register "maint check libthread-db"
      	and "maint set/show check-libthread-db".
      
      gdb/doc/ChangeLog:
      
      	* gdb.texinfo (Maintenance Commands): Document "maint check
      	libthread-db" and "maint set/show check-libthread-db".
      
      gdb/testsuite/ChangeLog:
      
      	* gdb.threads/check-libthread-db.exp: New file.
      	* gdb.threads/check-libthread-db.c: Likewise.
      66e8d8be
    • claziss's avatar
      [ARC] Fix handling of ARCv2 H-register class. · dc958481
      claziss authored
      For ARCv2, h-regs are only valid unitl r31.
      
      gas/
      2017-11-21  Claudiu Zissulescu <claziss@synopsys.com>
      
              * testsuite/gas/arc/hregs-err.s: New test.
      
      opcodes/
      2017-11-21  Claudiu Zissulescu <claziss@synopsys.com>
      
              * arc-opc.c (insert_rhv2): Check h-regs range.
      dc958481
    • H.J. Lu's avatar
      x86: Add tests for -n option of x86 assembler · 0ad71725
      H.J. Lu authored
      The -n command-line of x86 assembler disables optimization of alignment
      directives, like ".balign 8, 0x90", with multi-byte nop instructions
      such as leal 0(%esi),%esi.
      
      	PR gas/22464
      	* testsuite/gas/i386/align-1.s: New file.
      	* testsuite/gas/i386/align-1a.d: Likewise.
      	* testsuite/gas/i386/align-1b.d: Likewise.
      	* testsuite/gas/i386/i386.exp: Run align-1a and align-1b.
      0ad71725
    • GDB Administrator's avatar
      Automatic date update in version.in · c757658e
      GDB Administrator authored
      c757658e
  2. 21 Nov, 2017 20 commits
    • Jerome Guitton's avatar
      ravenscar: update inferior ptid with event ptid · 3b1b69bf
      Jerome Guitton authored
      When debugging a program using a ravenscar runtime, the thread
      layer sometimes gets confused, and even missing some threads.
      This was traced to an assumption that ravenscar_wait was making,
      which is that calling the "to_wait" target_ops method would
      set the inferior_ptid, so that we could then use that assumption
      to update our thread_list and current ptid. However, this has not
      been the case for quite a while now. This patch fixes the problem
      by assigning inferior_ptid the ptid returned by "to_wait".
      
      gdb/ChangeLog:
      
      	* ravenscar-thread.c (ravenscar_wait): Update inferior ptid
      	with event ptid from the lower layer before doing the
      	ravenscar-specific update.
      3b1b69bf
    • Joel Brobecker's avatar
      (Ada) crash connecting to TSIM simulator · 54aa6c67
      Joel Brobecker authored
      Connecting to a TSIM simulator over the remote protocol causes GDB
      to crash with the following failed assertion:
      
          (gdb) tar remote :1234
          Remote debugging using :1234
          /[...]/gdb/ravenscar-thread.c:182: internal-error: ravenscar_update_inferior_ptid: Assertion `!is_ravenscar_task (inferior_ptid)' failed.
          A problem internal to GDB has been detected,
          further debugging may prove unreliable.
          Quit this debugging session? (y or n) y
      
      What happens is the following. Upon connection to the target, GDB
      sends a 'qfThreadInfo' query, which is the query asking the target
      for the ID of the first thread, and TSIM replies 'm0':
      
          Sending packet: $qfThreadInfo#bb...Ack
          Packet received: m0
      
      As a result of this, GDB takes the '0' as the TID, and because of it,
      constructs a ptid whose value is {42000, 0, 0}. This trips our
      !is_ravenscar_task check, because all it does to identify threads
      corresponding to ravenscar tasks is that their lwp is null, because
      that's how we construct their ptid.
      
      But this is unfortunatly not sufficient when debugging with TSIM,
      because the thread ID that TSIM returns causes the creation of
      a ptid whose lwp is zero, which matches the current identification
      scheme and yet is clearly not a ravenscar task.
      
      The fix is to also make sure that the ptid's tid field is nonzero.
      
      gdb/ChangeLog:
      
              * ravenscar-thread.c (is_ravenscar_task): Also verify that
              the ptid's TID is nonzero.
      54aa6c67
    • Joel Brobecker's avatar
      problem debugging ravenscar programs if runtime is stripped · cf3fbed4
      Joel Brobecker authored
      Trying to debug a program using a stripped version of the ravenscar
      runtime, we can get the following error:
      
          (gdb) cont
          Continuing.
          Cannot find Ada_Task_Control_Block type. Aborting
      
      This is because the ravenscar-thread layer makes the assumption that
      the runtime is built the way we expect it, meaning that the Ada tasking
      units we rely on for Ada tasking debugging, are built with debugging
      information, and that this debug information has not been stripped from
      the runtime.
      
      When this assumption is not true, resuming such a program can trigger
      the error above, which then leads GDB a little confused. For instance,
      we can see things like:
      
           (gdb) bt
           Target is executing.
      
      This patch fixes the issue by disabling the ravenscar thread layer
      if we detect that the runtime is missing some of the debugging info
      we need in order to support Ada task debugging. This is the best
      we can do, as the ravenscar-thread layer actually depends on the
      ada-tasks layer to implement thread debugging.
      
      gdb/ChangeLog:
      
              * ada-lang.h (ada_get_tcb_types_info): Add declaration.
              * ada-tasks.c (ada_get_tcb_types_info): Renames get_tcb_types_info.
              Make non-static.  Change return type to char *.  Adjust code
              accordingly.  Rewrite the function's documentation.
              (read_atcb): Adjust call to get_tcb_types_info accordingly.
              * ravenscar-thread.c (ravenscar_inferior_created): Check that
              we have enough debugging information in the runtime to support
              Ada task debugging before we enable the ravenscar-thread layer.
      cf3fbed4
    • Joel Brobecker's avatar
      Add multiple-CPU support in ravenscar-thread.c · 9edcc12f
      Joel Brobecker authored
      This patch reworks the ravenscar-thread layer to remove the
      assumption that the target only has 1 CPU. In particular,
      when connected to a QEMU target over the remote protocol,
      QEMU reports each CPU as one thread. This patch adapts
      the ravenscar-thread layer to this, and adds a large comment
      explaining the general design of this unit.
      
      gdb/ChangeLog:
      
              * ada-lang.h (ada_get_task_info_from_ptid): Add declaration.
              * ada-tasks.c (ada_get_task_info_from_ptid): New function.
              * ravenscar-thread.c: Add into comment.
              (base_magic_null_ptid): Delete.
              (base_ptid): Change documentation.
              (ravenscar_active_task): Renames ravenscar_running_thread.
              All callers updated throughout.
              (is_ravenscar_task, ravenscar_get_thread_base_cpu): New function.
              (ravenscar_task_is_currently_active): Likewise.
              (get_base_thread_from_ravenscar_task): Ditto.
              (ravenscar_update_inferior_ptid): Adjust to handle multiple CPUs.
              (ravenscar_runtime_initialized): Likewise.
              (get_running_thread_id): Add new parameter "cpu".  Adjust
              implementation to handle this new parameter.
              (ravenscar_fetch_registers): Small adjustment to use
              is_ravenscar_task and ravenscar_task_is_currently_active in
              order to decide whether to use the target beneath or this
              module's arch_ops.
              (ravenscar_store_registers, ravenscar_prepare_to_store): Likewise.
              (ravenscar_stopped_by_sw_breakpoint): Use
              get_base_thread_from_ravenscar_task to get the underlying
              thread, rather than using base_ptid.
              (ravenscar_stopped_by_hw_breakpoint, ravenscar_stopped_by_watchpoint)
              (ravenscar_stopped_data_address, ravenscar_core_of_thread):
              Likewise.
              (ravenscar_inferior_created): Do not set base_magic_null_ptid.
      9edcc12f
    • Joel Brobecker's avatar
      Provide the "Base CPU" in output of "info task" (if set by runtime). · 65d40437
      Joel Brobecker authored
      At the user level, this patch enhances the debugger to print the ID
      of the base CPU a task is running on:
      
              (gdb) info task 3
              Ada Task: 0x13268
              Name: raven1
              Thread: 0x13280
              LWP: 0
       !!!->  Base CPU: 1
              No parent
              Base Priority: 127
              State: Runnable
      
      This new field is only printed when the base CPU is nonzero or, in
      other words, if the base CPU info is being provided by the runtime.
      For instance, on native systems, where threads/processes can "jump"
      from CPU to CPU, the info is not available, and the output of the
      command above then remains unchanged.
      
      At the internal level, the real purpose of this change is to prepare
      the way for ravenscar-thread to start handling SMP systems. For that,
      we'll need to know which CPU each task is running on...  More info
      on that in the commit that actually adds support for it.
      
      gdb/ChangeLog:
      
              * ada-lang.h (struct ada_task_info) <base_cpu>: New field.
              * ada-lang.c (struct atcb_fieldno) <base_cpu>: New field.
              (get_tcb_types_info): Set fieldnos.base_cpu.
              (read_atcb): Set task_info->base_cpu.
              (info_task): Print "Base CPU" info if set by runtime.
      65d40437
    • Joel Brobecker's avatar
      watchpoint regression debugging with remote protocol (bare metal) · e02544b2
      Joel Brobecker authored
      We have noticed a regression in our watchpoint support when debugging
      through the remote protocol a program running on a bare metal platform,
      when the program uses what we call the Ravenscar Runtime.
      
      This runtime is a subset of the Ada runtime defined by the Ravenscar
      Profile.  One of the nice things about this runtime is that it provides
      tasking, which is equivalent to the concept of threads in C (it is
      actually often mapped to threads, when available). For bare metal
      targets, however, there is no OS, and therefore no thread layer.
      What we did, then, was add a ravenscar-thread layer, which has insider
      knowledge of the runtime to get the list of threads, but also all
      necessary info to perform thread switching.
      
      For the record, the commit which caused the regression is:
      
          commit 799a2abe
          Date:   Mon Nov 30 16:05:16 2015 +0000
          Subject: remote: stop reason and watchpoint data address per thread
      
          Running local-watch-wrong-thread.exp with "maint set target-non-stop
          on" exposes that gdb/remote.c only records whether the target stopped
          for a breakpoint/watchpoint plus the watchpoint data address *for the
          last reported remote event*.  But in non-stop mode, we need to keep
          that info per-thread, as each thread can end up with its own
          last-status pending.
      
      Our testcase is very simple. We have a package defining a global
      variable named "Watch"...
      
          package Pck is
             Watch : Integer := 1974;
          end Pck;
      
      ... and a main subprogram which changes its value
      
          procedure Foo is
          begin
             Pck.Watch := Pck.Watch + 1;
          end Foo;
      
      To reproduce, we built our program as usual, started it in QEMU,
      and then connected GDB to QEMU...
      
          (gdb) target remote :4444
          (gdb) break _ada_foo
          (gdb) cont  <--- this is to make sure the program is started
                           and the variable we want to watch is initialized
      
      ... at which point we try to use a watchpoint on our global variable:
      
          (gdb) watch watch
      
      ... but, upon resuming the execution with a "cont", we expected to
      get a watchpoint-hit notification, such as...
      
          (gdb) cont
          Hardware watchpoint 2: watch
      
          Old value = 1974
          New value = 1975
          0xfff00258 in foo () at /[...]/foo.adb:6
          6       end Foo;
      
      ... but unfortunately, we get a SIGTRAP instead:
      
          (gdb) cont
          Program received signal SIGTRAP, Trace/breakpoint trap.
          foo () at /[...]/foo.adb:6
              6   end Foo;
      
      What happens is that, on the one hand, the change in remote.c
      now stores the watchpoint-hit notification info in the thread
      that received it; and on the other hand, we have a ravenscar-thread
      layer which manages the thread list on top of the remote protocol
      layer. The two of them get disconnected, and this eventually results
      in GDB not realizing that we hit a watchpoint.  Below is how:
      
      First, once connected and just before inserting our watchpoint,
      we have the ravenscar-thread layer which built the list of threads
      by extracting some info from inferior memory, giving us the following
      two threads:
      
            (gdb) info threads
            Id   Target Id         Frame
            1    Thread 0 "0Q@" (Ravenscar task) foo () at /[...]/foo.adb:5
          * 2    Thread 0x24618 (Ravenscar task) foo () at /[...]/foo.adb:5
      
      The first thread is the only thread QEMU told GDB about. The second
      one is a thread that the ravenscar-thread added. QEMU has now way
      to know about those threads, since they are really embedded inside
      the program; that's why we have the ravenscar layer, which uses
      inside-knowledge to extract the list of threads.
      
      Next, we insert a watchpoint, which applies to all threads. No problem
      so far.
      
      Then, we continue; meaning that GDB sends a Z2 packet to QEMU to
      get the watchpoint inserted, then a vCont to resume the program's
      execution. The program hits the watchpoints, and thererfore QEMU
      reports it back:
      
              Packet received: T05thread:01;watch:000022c4;
      
      Since QEMU knows about one thread and one thread only, it stands
      to reason that it would say that the event applies to thread:01,
      which is our first thread in the "info threads" listing. That
      thread has a ptid of {42000, lwp=1, tid=0}.
      
      This is where Pedro's change kicks in: Seeing this event, and
      having determined that the event was reported for thread 01,
      and therefore ptid {42000, lwp=1, tid=0}, it saves the watchpoint-hit
      event info in the private area of that thread/ptid. Once this is
      done, remote.c's event-wait layer returns.
      
      Enter the ravenscar-thread layer of the event-wait, which does
      a little dance to delegate the wait to underlying layers with
      ptids that those layers know about, and then when the target_beneath's
      to_wait is done, tries to figure out which thread is now the active
      thread. The code looks like this:
      
        1.    inferior_ptid = base_ptid;
        2.    beneath->to_wait (beneath, base_ptid, status, 0);
        3.    [...]
        4.        ravenscar_update_inferior_ptid ();
        5.
        6.    return inferior_ptid;
      
      Line 1 is where we reset inferior_ptid to the ptid that
      the target_beneath layer knows about, allowing us to then
      call its to_wait implementation (line 2). And then, upon
      return, we call ravenscar_update_inferior_ptid, which reads
      inferior memory to determine which thread is actually active,
      setting inferior_ptid accordingly. Then we return that
      inferior_ptid (which, again, neither QEMU and therefore nor
      the remote.c layer knows about).
      
      Upon return, we eventually arrive to the part where we try
      to handle the inferior event: we discover that we got a SIGTRAP
      and, as part of its handling, we call watchpoints_triggered,
      which calls target_stopped_by_watchpoint, which eventually
      remote_stopped_by_watchpoint, where Pedro's change kicks in
      again:
      
          struct thread_info *thread = inferior_thread ();
          return (thread->priv != NULL
                  && thread->priv->stop_reason == TARGET_STOPPED_BY_WATCHPOINT);
      
      Because the ravenscar-thread layer changed the inferior_ptid
      to the ptid of the active thread, inferior_thread now returns
      the private data of that thread. This is not the thread that
      QEMU reported the watchpoint-hit on, and thus, the function
      returns "no watchpoint hit, mister". Hence GDB not understanding
      the SIGTRAP, thus reporting it verbatim.
      
      The way we chose to fix the issue is by making sure that the
      ravenscar-thread layer doesn't let the remote layer be called
      with inferior_ptid being set to a thread that the remote layer
      does not know about.
      
      gdb/ChangeLog:
      
              * ravenscar-thread.c (ravenscar_stopped_by_sw_breakpoint)
              (ravenscar_stopped_by_hw_breakpoint, ravenscar_stopped_by_watchpoint)
              (ravenscar_stopped_data_address, ravenscar_core_of_thread):
              New functions.
              (init_ravenscar_thread_ops): Set the to_stopped_by_sw_breakpoint,
              to_stopped_by_hw_breakpoint, to_stopped_by_watchpoint,
              to_stopped_data_address and to_core_of_thread fields of
              ravenscar_ops.
      e02544b2
    • H.J. Lu's avatar
      Add a test for PR binutils/22451 · d6251545
      H.J. Lu authored
      Check in the object file generated from the older assembler as a
      compressed file.
      
      	PR binutils/22451
      	* testsuite/binutils-all/x86-64/objects.exp: New file.
      	* testsuite/binutils-all/x86-64/pr22451.o.bz2: Likewise.
      d6251545
    • Ulrich Weigand's avatar
      [PowerPC] Detect different long double floating-point formats · ed0f4273
      Ulrich Weigand authored
      Current versions of GCC support switching the format used for "long double"
      to either IBM double double or IEEE-128.  The resulting binary is marked
      via different setting of the Tag_GNU_Power_ABI_FP GNU attribute.
      
      This patch checks this attribute to detect the format of the default
      "long double" type and sets GDB's notion of the format accordingly.
      
      The patch also adds support for the "__ibm128" type, which always uses
      IBM double double format independent of the format used for "long double".
      
      A new test case verifies that all three types, "long double", "__float128",
      and "__ibm128" are correctly detected in all three compiler settings,
      the default setting, -mabi=ieeelongdouble, and -mabi=ibmlongdouble.
      
      gdb/ChangeLog:
      2017-11-21  Ulrich Weigand  <uweigand@de.ibm.com>
      
      	* ppc-tdep.h (enum powerpc_long_double_abi): New data type.
      	(struct gdbarch_tdep): New member long_double_abi.
      	* rs6000-tdep.c (rs6000_gdbarch_init): Initialize long_double_abi
      	member of tdep struct based on Tag_GNU_Power_ABI_FP attribute.
      	* ppc-linux-tdep.c (ppc_linux_init_abi): Install long double data
      	format depending on long_double_abi tdep member.
      	(ppc_floatformat_for_type): Handle __ibm128 type.
      
      gdb/testsuite/ChangeLog:
      2017-11-21  Ulrich Weigand  <uweigand@de.ibm.com>
      
      	* gdb.arch/ppc-longdouble.exp: New file.
      	* gdb.arch/ppc-longdouble.c: Likewise.
      ed0f4273
    • Pedro Alves's avatar
      gdb.ada/minsyms.exp: Don't hardcode the variable's address · a25d69c6
      Pedro Alves authored
      This new testcase has a test that fails like this here:
      
        $1 = (<data variable, no debug info> *) 0x60208c <some_minsym>
        (gdb) FAIL: gdb.ada/minsyms.exp: print &some_minsym
      
      The problem is that the testcase hardcodes an expected address for the
      "some_minsym" variable, which obviously isn't stable.
      
      Fix that by expecting $hex instead.
      
      gdb/testsuite/ChangeLog:
      2017-11-21  Pedro Alves  <palves@redhat.com>
      
      	* gdb.ada/minsyms.exp: Accept any address for 'some_minsym'.
      a25d69c6
    • Nick Clifton's avatar
      Stop the v850 linker from converting to other output formats whilst linking. · 2824e1bd
      Nick Clifton authored
      	PR 22419
      	* emultempl/v850elf.em (v850_create_output_section_statements):
      	New function.  Generate an error if attempting to convert the
      	format of the output file.
      	* testsuite/ld-unique/pr21529.d: Skip for the V850.
      	* testsuite/ld-elf/pr21884.d: Skip for the V850.
      2824e1bd
    • claziss's avatar
      [ARC] [COMMITTED] Update test pattern patching. · bd560f57
      claziss authored
      2017-11-21  Claudiu Zissulescu  <claziss@synopsys.com>
      
      	* testsuite/binutils-all/arc/objdump.exp: Update pattern matching
      	expression.
      bd560f57
    • claziss's avatar
      [ARC] Improve printing of pc-relative instructions. · 50d2740d
      claziss authored
      opcodes/
      2017-11-21  Claudiu Zissulescu <claziss@synopsys.com>
      
      	* arc-dis.c (print_insn_arc): Pretty print pc-relative offsets.
      	* arc-opc.c (SIMM21_A16_5): Make it pc-relative.
      
      gas/
      2017-11-21  Claudiu Zissulescu <claziss@synopsys.com>
      
      	* testsuite/gas/arc/b.d : Update test.
      	* testsuite/gas/arc/bl.d: Likewise.
      	* testsuite/gas/arc/jli-1.d: Likewise.
      	* testsuite/gas/arc/lp.d: Likewise.
      	* testsuite/gas/arc/pcl-relocs.d: Likewise.
      	* testsuite/gas/arc/pcrel-relocs.d: Likewise.
      	* testsuite/gas/arc/pic-relocs.d: Likewise.
      	* testsuite/gas/arc/plt-relocs.d: Likewise.
      	* testsuite/gas/arc/pseudos.d: Likewise.
      	* testsuite/gas/arc/relax-avoid2.d: Likewise.
      	* testsuite/gas/arc/relax-avoid3.d: Likewise.
      	* testsuite/gas/arc/relax-b.d: Likewise.
      	* testsuite/gas/arc/tls-relocs.d: Likewise.
      	* testsuite/gas/arc/relax-add01.d: Likewise.
      	* testsuite/gas/arc/relax-add04.d: Likewise.
      	* testsuite/gas/arc/relax-ld01.d: Likewise.
      	* testsuite/gas/arc/relax-sub01.d: Likewise.
      	* testsuite/gas/arc/relax-sub02.d: Likewise.
      	* testsuite/gas/arc/relax-sub04.d: Likewise.
      	* testsuite/gas/arc/pcl-print.s: New file.
      	* testsuite/gas/arc/pcl-print.d: Likewise.
      	* testsuite/gas/arc/nps400-12.d: Likewise.
      
      ld/
      2017-11-21  Claudiu Zissulescu <claziss@synopsys.com>
      
      	* testsuite/ld-arc/jli-simple.d: Update test.
      50d2740d
    • Nick Clifton's avatar
      Add ability to follow dwo links to readelf/objdump. · d85bf2ba
      Nick Clifton authored
      	* dwarf.c (dwo_name, dwo_dir, dwo_id, dwo_id_len): New variables.
      	(read_and_display_attr_value): Record dwo variables if requested.
      	(display_augmentation_data): Rename to display_data and make
      	generic.
      	(load_dwo_file): New function.  Loads a separate dwarf object
      	file.
      	(load_separate_debug_file): Add reporting and loading of separate
      	dwarf objet files.
      	* readelf.c (process_section_headers): Add do_debug_links to list
      	of flags requiring a debug dump.
      	(display_debug_section): Tidy up code.
      	* doc/debug.options.texi: Add note that dwo links will also be
      	followed.
      	* testsuite/binutils-all/debuglink.s: Tidy code.
      	* testsuite/binutils-all/dwo.s: New test file.
      	* testsuite/binutils-all/readelf.wk2: New file - expected output
      	from readelf.
      	* testsuite/binutils-all/readelf.exp: Run the new test.
      d85bf2ba
    • Simon Marchi's avatar
      Fix build failure in darwin-nat.c · 0fc76421
      Simon Marchi authored
      Fix:
      
      /Users/simark/src/binutils-gdb/gdb/darwin-nat.c:2404:3: error: no matching function for call to 'add_setshow_boolean_cmd'
        add_setshow_boolean_cmd ("mach-exceptions", class_support,
        ^~~~~~~~~~~~~~~~~~~~~~~
      
      gdb/ChangeLog:
      
      	* darwin-nat.c (set_enable_mach_exceptions): Constify parameter.
      0fc76421
    • Alan Modra's avatar
      Add NULL bfd test to elf_symbol_from · 0ee5a0e4
      Alan Modra authored
      A followup to PR22443.
      
      	* elf-bfd.h (elf_symbol_from): Check for NULL symbol bfd.
      	* elfcode.h (elf_slurp_reloc_table_from_section): Add FIXME comment.
      0ee5a0e4
    • Alan Modra's avatar
      xtensa error message · bf3d1399
      Alan Modra authored
      	* config/tc-xtensa.c (finish_vinsn): Avoid multiple ngettext calls
      	in error message.
      bf3d1399
    • Pedro Alves's avatar
      Fix mapped_index::find_name_components_bounds upper bound computation · e6b2f5ef
      Pedro Alves authored
      Here we want to find where we'd insert "after", so we want
      std::lower_bound, not std::upper_bound.
      
      gdb/ChangeLog:
      2017-11-21  Pedro Alves  <palves@redhat.com>
      
      	* dwarf2read.c (mapped_index::find_name_components_bounds)
      	<completion mode, upper bound>: Use std::lower_bound instead of
      	std::upper_bound.
      	(test_mapped_index_find_name_component_bounds): Remove incorrect
      	"t1_fund" from expected symbols.
      e6b2f5ef
    • Pedro Alves's avatar
      Unit test name-component bounds searching directly · 5c58de74
      Pedro Alves authored
      This commit factors out the name-components-vector building and bounds
      searching out of dw2_expand_symtabs_matching_symbol into separate
      functions, and adds unit tests that:
      
       - expose both the latent bug mentioned in the previous commit, and
         also,
      
       - for completeness exercise the 0xff character handling fixed in the
         previous commit more directly.
      
      The actual fix for the now-exposed bug is left for the following
      patch.
      
      gdb/ChangeLog:
      2017-11-21  Pedro Alves  <palves@redhat.com>
      
      	* dwarf2read.c (mapped_index::name_components_casing): New field.
      	(mapped_index) <build_name_components,
      	find_name_components_bounds): Declare new methods.
      	(mapped_index::find_name_components_bounds)
      	(mapped_index::build_name_components): New methods, factored out
      	from dw2_expand_symtabs_matching_symbol.
      	(check_find_bounds_finds)
      	(test_mapped_index_find_name_component_bounds): New.
      	(run_test): Rename to ...
      	(test_dw2_expand_symtabs_matching_symbol): ... this.
      	(run_test): Reimplement.
      5c58de74
    • Pedro Alves's avatar
      0xff chars in name components table; cp-name-parser lex UTF-8 identifiers · e1ef7d7a
      Pedro Alves authored
      The find-upper-bound-for-completion algorithm in the name components
      accelerator table in dwarf2read.c increments a char in a string, and
      asserts that it's not incrementing a 0xff char, but that's incorrect.
      
      First, we shouldn't be calling gdb_assert on input.
      
      Then, if "char" is signed, comparing a caracther with "0xff" will
      never yield true, which is caught by Clang with:
      
        error: comparison of constant 255 with expression of type '....' (aka 'char') is always true [-Werror,-Wtautological-constant-out-of-range-compare]
      	    gdb_assert (after.back () != 0xff);
      			~~~~~~~~~~~~~ ^  ~~~~
      
      And then, 0xff is a valid character on non-UTF-8/ASCII character sets.
      E.g., it's 'ÿ' in Latin1.  While GCC nor Clang support !ASCII &&
      !UTF-8 characters in identifiers (GCC supports UTF-8 characters only
      via UCNs, see https://gcc.gnu.org/onlinedocs/cpp/Character-sets.html),
      but other compilers might (Visual Studio?), so it doesn't hurt to
      handle it correctly.  Testing is covered by extending the
      dw2_expand_symtabs_matching unit tests with relevant cases.
      
      However, without further changes, the unit tests still fail...  The
      problem is that cp-name-parser.y assumes that identifiers are ASCII
      (via ISALPHA/ISALNUM).  This commit fixes that too, so that we can
      unit test the dwarf2read.c changes.  (The regular C/C++ lexer in
      c-lang.y needs a similar treatment, but I'm leaving that for another
      patch.)
      
      While doing this, I noticed a thinko in the computation of the upper
      bound for completion in dw2_expand_symtabs_matching_symbol.  We're
      using std::upper_bound but we should use std::lower_bound.  I extended
      the unit test with a case that I thought would expose it, this one:
      
       +  /* These are used to check that the increment-last-char in the
       +     matching algorithm for completion doesn't match "t1_fund" when
       +     completing "t1_func".  */
       +  "t1_func",
       +  "t1_func1",
       +  "t1_fund",
       +  "t1_fund1",
      
      The algorithm actually returns "t1_fund1" as lower bound, so "t1_fund"
      matches incorrectly.  But turns out the problem is masked because
      later here:
      
        for (;lower != upper; ++lower)
          {
            const char *qualified = index.symbol_name_at (lower->idx);
      
            if (!lookup_name_matcher.matches (qualified)
      
      the lookup_name_matcher.matches check above filters out "t1_fund"
      because that doesn't start with "t1_func".
      
      I'll fix the latent bug in follow up patches, after factoring things
      out a bit in a way that allows unit testing the relevant code more
      directly.
      
      gdb/ChangeLog:
      2017-11-21  Pedro Alves  <palves@redhat.com>
      
      	* cp-name-parser.y (cp_ident_is_alpha, cp_ident_is_alnum): New.
      	(symbol_end): Use cp_ident_is_alnum.
      	(yylex): Use cp_ident_is_alpha and cp_ident_is_alnum.
      	* dwarf2read.c (make_sort_after_prefix_name): New function.
      	(dw2_expand_symtabs_matching_symbol): Use it.
      	(test_symbols): Add more symbols.
      	(run_test): Add tests.
      e1ef7d7a
    • GDB Administrator's avatar
      Automatic date update in version.in · 97529824
      GDB Administrator authored
      97529824
  3. 20 Nov, 2017 16 commits
    • Pedro Alves's avatar
      Fix gdb.base/whatis-ptype-typedefs.exp on 32-bit archs · 73fcf641
      Pedro Alves authored
      The gdb.base/whatis-ptype-typedefs.exp testcase has several tests that
      fail on 32-bit architectures.  E.g., on 'x86-64 -m32', I see:
      
       ...
       FAIL: gdb.base/whatis-ptype-typedefs.exp: lang=c: cast: whatis (float_typedef) v_uchar_array_t_struct_typedef (invalid)
       FAIL: gdb.base/whatis-ptype-typedefs.exp: lang=c: cast: ptype (float_typedef) v_uchar_array_t_struct_typedef (invalid)
       ...
      
      gdb.log:
      
       (gdb) whatis (float_typedef) v_uchar_array_t_struct_typedef
       type = float_typedef
       (gdb) FAIL: gdb.base/whatis-ptype-typedefs.exp: lang=c: cast: whatis (float_typedef) v_uchar_array_t_struct_typedef (invalid)
      
      As Simon explained [1], the issue boils down to the fact that on
      64-bit, this is an invalid cast:
      
       (gdb) p (float_typedef) v_uchar_array_t_struct_typedef
       Invalid cast.
      
      while on 32 bits it is valid:
      
       (gdb) p (float_typedef) v_uchar_array_t_struct_typedef
       $1 = 1.16251721e-41
      
      The expression basically tries to cast an array (which decays to a
      pointer) to a float.  The cast works on 32 bits because a float and a
      pointer are of the same size, and value_cast works in that case:
      
      ~~~
         More general than a C cast: accepts any two types of the same length,
         and if ARG2 is an lvalue it can be cast into anything at all.  */
      ~~~
      
      On 64 bits, they are not the same size, so it ends throwing the
      "Invalid cast" error.
      
      The testcase is expecting the invalid cast behavior, thus the FAILs.
      
      A point of these tests was to cover as many code paths in value_cast
      as possible, as a sort of documentation of the current behavior:
      
          # The main idea here is testing all the different paths in the
          # value casting code in GDB (value_cast), making sure typedefs are
          # preserved.
      ...
          # We try all combinations, even those that don't parse, or are
          # invalid, to catch the case of a regression making them
          # inadvertently valid.  For example, these convertions are
          # invalid:
      ...
      
      In that spirit, this commit makes the testcase adjust itself depending
      on size of floats and pointers, and also test floats of different
      sizes.
      
      Passes cleanly on x86-64 GNU/Linux both -m64/-m32.
      
      [1] - https://sourceware.org/ml/gdb-patches/2017-11/msg00382.html
      
      gdb/ChangeLog:
      2017-11-20  Pedro Alves  <palves@redhat.com>
      
      	* gdb.base/whatis-ptype-typedefs.c (double_typedef)
      	(long_double_typedef): New typedefs.
      	Use DEF on double and long double.
      	* gdb.base/whatis-ptype-typedefs.exp: Add double and long double
      	cases.
      	(run_tests): New 'float_ptr_same_size', 'double_ptr_same_size',
      	and 'long_double_ptr_same_size' locals.  Use them to decide
      	whether cast from array/function to float is valid/invalid.
      73fcf641
    • Nick Clifton's avatar
      Fix handling of GNU Property notes that are not in a GNU NOTE PROPERTY section. · b77db948
      Nick Clifton authored
      	PR 22450
      gas	* elf-properties.c (_bfd_elf_link_setup_gnu_properties): Skip
      	objects without a GNU_PROPERTY note section when looking for a bfd
      	onto which notes can be accumulated.
      
      ld	* testsuite/ld-elf/elf.exp: Add --defsym ALIGN=2|3 to assembler
      	command line depending upon the size of the target address space.
      	* testsuite/ld-elf/pr22450.s: New test file.
      	* testsuite/ld-elf/pr22450.d: New test driver.
      	* testsuite/config/default.exp: Add note that LD_CLASS refers to
      	the size of the host linker not the size of the target linker.
      b77db948
    • Alan Modra's avatar
      mingw gas testsuite fix · b7486a74
      Alan Modra authored
      Some x86_64 targets pad sections with nops.
      
      	* testsuite/gas/i386/x86-64-reg-bad.l: Accept trailing padding.
      b7486a74
    • Alan Modra's avatar
      PR22451, strip no longer works on older object files · 28e07a05
      Alan Modra authored
      Setting SHF_GROUP unconditionally on rel/rela sections associated with
      SHF_GROUP sections fails badly with objcopy/strip and ld -r if the
      input file SHT_GROUP section didn't specify the rel/rela sections.
      This patch rearranges where SHF_GROUP is set for rel/rela sections.
      
      	PR 22451
      	PR 22460
      	* elf.c (_bfd_elf_init_reloc_shdr): Delete "sec_hdr" parameter
      	and leave rel_hdr->sh_flags zero.  Update calls.
      	(bfd_elf_set_group_contents): Check input rel/rela SHF_GROUP
      	flag when !gas before adding rel/rela section to group.  Set
      	output rel/rela SHF_GROUP flags.
      28e07a05
    • Simon Marchi's avatar
      Remove usage of find_inferior when calling kill_one_lwp_callback · 578290ec
      Simon Marchi authored
      Replace with for_each_thread.
      
      gdb/gdbserver/ChangeLog:
      
      	* linux-low.c (kill_one_lwp_callback): Return void, take
      	argument directly, don't filter on pid.
      	(linux_kill): Use for_each_thread.
      578290ec
    • Simon Marchi's avatar
      Remove usages of find_thread when calling need_step_over_p · eca55aec
      Simon Marchi authored
      Replace with find_thread.
      
      gdb/gdbserver/ChangeLog:
      
      	* linux-low.c (need_step_over_p): Return bool, remove dummy
      	argument.
      	(linux_resume, proceed_all_lwps): Use find_thread.
      eca55aec
    • Simon Marchi's avatar
      Remove usage of find_thread when calling resume_status_pending_p · 25c28b4d
      Simon Marchi authored
      Replace with find_thread.  Instead of setting the flag in the callback,
      make the callback return true/false, and check the result against NULL
      in the caller.
      
      gdb/gdbserver/ChangeLog:
      
      	* linux-low.c (resume_status_pending_p): Return bool, remove
      	flag_p argument.
      	(linux_resume): Use find_thread.
      25c28b4d
    • Simon Marchi's avatar
      Remove usage of find_inferior when calling linux_set_resume_request · 5fdda392
      Simon Marchi authored
      Replace it with for_each_thread.
      
      gdb/gdbserver/ChangeLog:
      
      	* linux-low.c (struct thread_resume_array): Remove.
      	(linux_set_resume_request): Return void, take arguments
      	directly.
      	(linux_resume): Use for_each_thread.
      5fdda392
    • Simon Marchi's avatar
      Remove usage of find_inferior in linux_stabilize_threads · fcb056a5
      Simon Marchi authored
      Simply replace with find_thread.
      
      gdb/gdbserver/ChangeLog:
      
      	* linux-low.c (stuck_in_jump_pad_callback): Change prototype,
      	return bool, remove data argument.
      	(linux_stabilize_threads): Use find_thread.
      fcb056a5
    • Simon Marchi's avatar
      Remove usage of find_inferior in unsuspend_all_lwps · 139720c5
      Simon Marchi authored
      Replace with for_each_thread.  I inlined unsuspend_one_lwp in
      unsuspend_all_lwps, since it is very simple.
      
      gdb/gdbserver/ChangeLog:
      
      	* linux-low.c (unsuspend_one_lwp): Remove.
      	(unsuspend_all_lwps): Use for_each_thread, inline code from
      	unsuspend_one_lwp.
      139720c5
    • Simon Marchi's avatar
      Remove usage of find_inferior in iterate_over_lwps · 6d1e5673
      Simon Marchi authored
      Replace find_inferior with find_thread.  Since it may be useful in the
      future, I added another overload to find_thread which filters based on a
      ptid (using ptid_t::matches), so now iterate_over_lwps doesn't have to
      do the filtering itself.  iterate_over_lwps_filter is removed and
      inlined into iterate_over_lwps.
      
      gdb/gdbserver/ChangeLog:
      
      	* gdbthread.h (find_thread): Add overload with ptid_t filter.
      	* linux-low.c (struct iterate_over_lwps_args): Remove.
      	(iterate_over_lwps_filter): Remove.
      	(iterate_over_lwps): Use find_thread.
      6d1e5673
    • Simon Marchi's avatar
      Remove usage of find_inferior in reset_lwp_ptrace_options_callback · bbf550d5
      Simon Marchi authored
      Replace with for_each_thread, and inline code from
      reset_lwp_ptrace_options_callback.
      
      gdb/gdbserver/ChangeLog:
      
      	* linux-low.c (reset_lwp_ptrace_options_callback): Remove.
      	(linux_handle_new_gdb_connection): Use for_each_thread, inline
      	code from reset_lwp_ptrace_options_callback.
      bbf550d5
    • Simon Marchi's avatar
      Remove usages of find_inferior in linux-arm-low.c · 00192f77
      Simon Marchi authored
      Replace two usages with the overload of for_each_thread that filters on
      pid.  It allows to simplify the callback a little bit.
      
      gdb/gdbserver/ChangeLog:
      
      	* linux-arm-low.c (struct update_registers_data): Remove.
      	(update_registers_callback): Return void, take arguments
      	directly, don't check thread's pid.
      	(arm_insert_point, arm_remove_point): Use for_each_thread.
      00192f77
    • Simon Marchi's avatar
      Remove usage of find_inferior in win32-low.c · 2bee2b6c
      Simon Marchi authored
      Replace with for_each_thread.
      
      gdb/gdbserver/ChangeLog:
      
      	* win32-low.c (continue_one_thread): Return void, take argument
      	directly.
      	(child_continue): Use for_each_thread.
      2bee2b6c
    • Simon Marchi's avatar
      Remove usage of find_inferior in win32-i386-low.c · 0b360f19
      Simon Marchi authored
      Straightforward replacement of find_inferior with the overload of
      for_each_thread that filters on pid.  I am able to build-test this
      patch, but not run it.
      
      gdb/gdbserver/ChangeLog:
      
      	* win32-i386-low.c (update_debug_registers_callback): Rename
      	to ...
      	(update_debug_registers): ... this, return void, remove pid_p arg.
      	(x86_dr_low_set_addr, x86_dr_low_set_control): Use for_each_thread.
      0b360f19
    • Cary Coutant's avatar
      Fix typo in ChangeLog entry. · 9c512d88
      Cary Coutant authored
      9c512d88