1. 25 Aug, 2018 5 commits
    • Kevin Buettner's avatar
      Disassemble blocks with non-contiguous ranges · 9fef6896
      Kevin Buettner authored
      This patch adds support for disassembly of blocks with non-contiguous
      ranges.  These blocks are printed as follows:
      
      (gdb) disassemble foo
      Dump of assembler code for function foo:
      Address range 0x401136 to 0x401151:
         0x0000000000401136 <+0>:     push   %rbp
         0x0000000000401137 <+1>:     mov    %rsp,%rbp
         0x000000000040113a <+4>:     callq  0x401134 <bar>
         0x000000000040113f <+9>:     mov    0x2eef(%rip),%eax        # 0x404034 <e>
         0x0000000000401145 <+15>:    test   %eax,%eax
         0x0000000000401147 <+17>:    je     0x40114e <foo+24>
         0x0000000000401149 <+19>:    callq  0x401128 <foo+4294967282>
         0x000000000040114e <+24>:    nop
         0x000000000040114f <+25>:    pop    %rbp
         0x0000000000401150 <+26>:    retq
      Address range 0x401128 to 0x401134:
         0x0000000000401128 <+-14>:   push   %rbp
         0x0000000000401129 <+-13>:   mov    %rsp,%rbp
         0x000000000040112c <+-10>:   callq  0x401126 <baz>
         0x0000000000401131 <+-5>:    nop
         0x0000000000401132 <+-4>:    pop    %rbp
         0x0000000000401133 <+-3>:    retq
      End of assembler dump.
      
      This is an actual dump from the test case that I constructed for
      this work.  The ranges are printed in the order encountered in the
      debug info. For the above example, note that the second range occupies
      lower addresses than the first range.
      
      Functions with contiguous ranges are still printed as follows:
      
      (gdb) disassemble main
      Dump of assembler code for function main:
         0x0000000000401151 <+0>:     push   %rbp
         0x0000000000401152 <+1>:     mov    %rsp,%rbp
         0x0000000000401155 <+4>:     callq  0x401136 <foo>
         0x000000000040115a <+9>:     mov    $0x0,%eax
         0x000000000040115f <+14>:    pop    %rbp
         0x0000000000401160 <+15>:    retq
      End of assembler dump.
      
      gdb/ChangeLog:
      
      	* cli/cli-cmds.c (block.h): Include.
      	(print_disassembly): Handle printing of non-contiguous blocks.
      	(disassemble_current_function): Likewise.
      	(disassemble_command): Likewise.
      9fef6896
    • Kevin Buettner's avatar
      Add support for non-contiguous blocks to find_pc_partial_function · 11c9ee15
      Kevin Buettner authored
      This change adds an optional output parameter BLOCK to
      find_pc_partial_function.  If BLOCK is non-null, then *BLOCK will be
      set to the address of the block corresponding to the function symbol
      if such a symbol was found during lookup.  Otherwise it's set to the
      NULL value.  Callers may wish to use the block information to
      determine whether the block contains any non-contiguous ranges.  The
      caller may also iterate over or examine those ranges.
      
      When I first started looking at the broken stepping behavior associated
      with functions w/ non-contiguous ranges, I found that I could "fix"
      the problem by disabling the find_pc_partial_function cache.  It would
      sometimes happen that the PC passed in would be between the low and
      high cache values, but would be in some other function that happens to
      be placed in between the ranges for the cached function.  This caused
      incorrect values to be returned.
      
      So dealing with this cache turns out to be very important for fixing
      this problem.  I explored three different ways of dealing with the
      cache.
      
      My first approach was to clear the cache when a block was encountered
      with more than one range.  This would cause the non-cache pathway to
      be executed on the next call to find_pc_partial_function.
      
      Another approach, which I suspect is slightly faster, checks to see
      whether the PC is within one of the ranges associated with the cached
      block.  If so, then the cached values can be used.  It falls back to
      the original behavior if there is no cached block.
      
      The current approach, suggested by Simon Marchi, is to restrict the
      low/high pc values recorded for the cache to the beginning and end of
      the range containing the PC value under consideration.  This allows us
      to retain the simple (and fast) test for determining whether the
      memoized (cached) values apply to the PC passed to
      find_pc_partial_function.
      
      Another choice that had to be made regards setting *ADDRESS and
      *ENDADDR.  There are three possibilities which might make sense:
      
      1) *ADDRESS and *ENDADDR represent the lowest and highest address
         of the function.
      2) *ADDRESS and *ENDADDR are set to the start and end address of
         the range containing the entry pc.
      3) *ADDRESS and *ENDADDR are set to the start and end address of
         the range in which PC is found.
      
      An earlier version of this patch implemented option #1.  I found out
      that it's not very useful though and, in fact, returns results that
      are incorrect when used in the context of determining the start and
      end of the function for doing prologue analysis.  While debugging a
      function in which the entry pc was in the second range (of a function
      containing two non-contiguous ranges), I noticed that
      amd64_skip_prologue called find_pc_partial_function - the returned
      start address was set to the beginning of the first range.  This is
      incorrect for this function.  What was also interesting was that this
      first invocation of find_pc_partial_function correctly set the cache
      for the PC on which it had been invoked, but a slightly later call
      from skip_prologue_using_sal could not use this cached value because
      it was now being used to lookup the very lowest address of the
      function - which is in a range not containing the entry pc.
      
      Option #2 is attractive as it would provide a desirable result
      when used in the context of prologue analysis.  However, many callers,
      including some which do prologue analysis want the condition
      *ADDRESS <= PC < *ENDADDR to hold.  This will not be the case when
      find_pc_partial_function is called on a PC that's in a non-entry-pc
      range.  A later patch to this series adds
      find_function_entry_range_from_pc as a wrapper of
      find_pc_partial_function.
      
      Option #3 causes the *ADDRESS <= PC < *ENDADDR property to hold.  If
      find_pc_partial_function is called with a PC that's within entry pc's
      range, then it will correctly return the limits of that range.  So, if
      the result of a minsym search is passed to find_pc_partial_function
      to find the limits, then correct results will be achieved.  Returned
      limits (for prologue analysis) won't be correct when PC is within some
      other (non-entry-pc) range.  I don't yet know how big of a problem
      this might be; I'm guessing that it won't be a serious problem - if a
      compiler generates functions which have non-contiguous ranges, then it
      also probably generates DWARF2 CFI which makes a lot of the old
      prologue analysis moot.
      
      I've implemented option #3 for this version of the patch.  I don't see
      any regressions for x86-64.  Moreover, I don't expect to see
      regressions for other targets either simply because
      find_pc_partial_function behaves the same as it did before for the
      contiguous address range case.  That said, there may be some
      adjustments needed if GDB encounters a function requiring prologue
      analysis which occupies non-contiguous ranges.
      
      gdb/ChangeLog:
      
      	* symtab.h (find_pc_partial_function): Add new parameter `block'.
      	* blockframe.c (cache_pc_function_block): New static global.
      	(clear_pc_function_cache): Clear cache_pc_function_block.
      	(find_pc_partial_function): Move comment to symtab.h.  Add
      	support for non-contiguous blocks.
      11c9ee15
    • Kevin Buettner's avatar
      Record explicit block ranges from dwarf2read.c · 8cad3755
      Kevin Buettner authored
      This change sets BLOCK_RANGES for the block under consideration by
      calling make_blockranges().  This action is performed in
      dwarf2_record_block_ranges().
      
      It should be noted that dwarf2_record_block_ranges() already does some
      recording of the range via a call to record_block_range().  The ranges
      recorded in that fashion end up in the address map associated with the
      blockvector for the compilation unit's symtab.  Given an address, the
      addrmap provides a fast way of finding the block containing that
      address.  The address map does not, however, provide a convenient way
      of determining which address ranges make up a particular block.
      
      While reading a set of ranges, a vector of pairs is used to collect
      the starting and ending addresses for each range in the block.  Once
      all of the ranges for a block have been collected, make_blockranges()
      is called to fill in BLOCK_RANGES for the block.
      
      The ranges are stored for the block in the order that they're read
      from the debug info.  For DWARF, the starting address of the first
      range of the block will be the entry pc in cases where DW_AT_entry_pc
      is not present.  (Well, that would ideally be the case.  At the moment
      DW_AT_entry_pc is not being handled.)
      
      gdb/ChangeLog:
      
      	* dwarf2read.c (dwarf2_record_block_ranges): Fill in BLOCK_RANGES
      	for block.
      8cad3755
    • Kevin Buettner's avatar
      Add block range data structure for blocks with non-contiguous address ranges · 76dae9eb
      Kevin Buettner authored
      This patch does the following:
      
      - Introduces a block range data structure which is accessed via
        a new field in struct block.
      - Defines several macros for accessing block ranges.
      - Defines a new function, make_blockrange, which is responsible for
        creating the new data structure.
      
      It should be noted that some support for non-contiguous ranges already
      existed in GDB in the form of blockvector addrmaps.  This support
      allowed GDB to quickly find a block containing a particular address
      even when the block consists of non-contiguous addresses.  See
      find_block_in_blockvector() in block.c, dwarf2_record_block_ranges()
      in dwarf2read.c, and record_block_range() in buildsym.c.
      
      Addrmaps do not provide a convenient way to examine address ranges
      associated with a particular block.  This data structure (and its
      interface) is set up for quickly finding the value (which in this case
      is a block) associated with a particular address.  The interface
      does not include a method for doing a reverse mapping from blocks to
      addresses.  A linear time mapping might be attempted via use of the
      addrmap's foreach method, but this is not as straightforward as it
      might first appear due to the fact that blocks corresponding to inline
      function instances and lexical blocks w/ variables end up getting
      interspersed in in the set of transitions.
      
      Note:  If this approach is deemed to be too expensive in terms of
      space, an alternate approach might be to attempt the linear time
      mapping noted above.  find_pc_partial_function() needs to be able to
      quickly know whether there are discontiguous ranges, so a flag for
      this property would have to be added to struct block.  Also integral
      to this set of changes is the concept of an "entry pc" which might be
      different from the block's start address.  An entry_pc field would
      also need to be added to struct block.  This does not result in any
      space savings in struct block though since the space for the flag and
      entry_pc use more space than the blockranges struct pointer that I've
      added.  There would, however, be some space savings due to the fact
      that the new data structures that I've added for this patch would not
      need to be allocated.  (I happen to like the approach I've come up
      with, but I wanted to mention another possibility just in case someone
      does not.)
      
      gdb/ChangeLog:
      
      	* block.h (blockrange, blockranges): New struct declarations.
      	(struct block): Add new field named `ranges'.
      	(BLOCK_RANGES, BLOCK_NRANGES, BLOCK_RANGE, BLOCK_CONTIGUOUS_P)
      	(BLOCK_RANGE_START, BLOCK_RANGE_END, BLOCK_ENTRY_PC): New
      	macros for accessing ranges in struct block.
      	(make_blockranges): New declaration.
      	block.c (make_blockranges): New function.
      76dae9eb
    • GDB Administrator's avatar
      Automatic date update in version.in · 35f0c5a6
      GDB Administrator authored
      35f0c5a6
  2. 24 Aug, 2018 2 commits
    • Pedro Alves's avatar
      Fix 8.2 regression in gdb.python/py-evthreads.exp w/ gdbserver (PR gdb/23379) · 0e84db8c
      Pedro Alves authored
      This commit fixes a 8.1->8.2 regression exposed by
      gdb.python/py-evthreads.exp when testing with
      --target_board=native-gdbserver.
      
      gdb.log shows:
      
        src/gdb/thread.c:93: internal-error: thread_info* inferior_thread(): Assertion `tp' failed.
        A problem internal to GDB has been detected,
        further debugging may prove unreliable.
        Quit this debugging session? (y or n) FAIL: gdb.python/py-evthreads.exp: run to breakpoint 1 (GDB internal error)
      
      A backtrace shows (frames #2 and #10 highlighted) that the assertion
      fails when GDB is setting up the connection to the remote target, in
      non-stop mode:
      
        #0  0x0000000000622ff0 in internal_error(char const*, int, char const*, ...) (file=0xc1ad98 "src/gdb/thread.c", line=93, fmt=0xc1ad20 "%s: Assertion `%s' failed.") at src/gdb/common/errors.c:54
        #1  0x000000000089567e in inferior_thread() () at src/gdb/thread.c:93
      = #2  0x00000000004da91d in get_event_thread() () at src/gdb/python/py-threadevent.c:38
        #3  0x00000000004da9b7 in create_thread_event_object(_typeobject*, _object*) (py_type=0x11574c0 <continue_event_object_type>, thread=0x0)
            at src/gdb/python/py-threadevent.c:60
        #4  0x00000000004bf6fe in create_continue_event_object() () at src/gdb/python/py-continueevent.c:27
        #5  0x00000000004bf738 in emit_continue_event(ptid_t) (ptid=...) at src/gdb/python/py-continueevent.c:40
        #6  0x00000000004c7d47 in python_on_resume(ptid_t) (ptid=...) at src/gdb/python/py-inferior.c:108
        #7  0x0000000000485bfb in std::_Function_handler<void (ptid_t), void (*)(ptid_t)>::_M_invoke(std::_Any_data const&, ptid_t&&) (__functor=..., __args#0=...) at /usr/include/c++/7/bits/std_function.h:316
        #8  0x000000000089b416 in std::function<void (ptid_t)>::operator()(ptid_t) const (this=0x12aa600, __args#0=...)
            at /usr/include/c++/7/bits/std_function.h:706
        #9  0x000000000089aa0e in gdb::observers::observable<ptid_t>::notify(ptid_t) const (this=0x118a7a0 <gdb::observers::target_resumed>, args#0=...)
            at src/gdb/common/observable.h:106
      = #10 0x0000000000896fbe in set_running(ptid_t, int) (ptid=..., running=1) at src/gdb/thread.c:880
        #11 0x00000000007f750f in remote_target::remote_add_thread(ptid_t, bool, bool) (this=0x12c5440, ptid=..., running=true, executing=true) at src/gdb/remote.c:2434
        #12 0x00000000007f779d in remote_target::remote_notice_new_inferior(ptid_t, int) (this=0x12c5440, currthread=..., executing=1)
            at src/gdb/remote.c:2515
        #13 0x00000000007f9c44 in remote_target::update_thread_list() (this=0x12c5440) at src/gdb/remote.c:3831
        #14 0x00000000007fb922 in remote_target::start_remote(int, int) (this=0x12c5440, from_tty=0, extended_p=0)
            at src/gdb/remote.c:4655
        #15 0x00000000007fd102 in remote_target::open_1(char const*, int, int) (name=0x1a4f45e "localhost:2346", from_tty=0, extended_p=0)
            at src/gdb/remote.c:5638
        #16 0x00000000007fbec1 in remote_target::open(char const*, int) (name=0x1a4f45e "localhost:2346", from_tty=0)
            at src/gdb/remote.c:4862
      
      So on frame #10, we're marking a newly-discovered thread as running,
      and that causes the Python API to emit a gdb.ContinueEvent.
      gdb.ContinueEvent is a gdb.ThreadEvent, and as such includes the event
      thread as the "inferior_thread" attribute.  The problem is that when
      we get to frame #3/#4, we lost all references to the thread that is
      being marked as running.  create_continue_event_object assumes that it
      is the current thread, which is not true in this case.
      
      Fix this by passing down the right thread in
      create_continue_event_object.  Also remove
      create_thread_event_object's default argument and have the only other
      caller left pass down the right thread explicitly too.
      
      gdb/ChangeLog:
      2018-08-24  Pedro Alves  <palves@redhat.com>
      	    Simon Marchi  <simon.marchi@ericsson.com>
      
      	PR gdb/23379
      	* python/py-continueevent.c: Include "gdbthread.h".
      	(create_continue_event_object): Add intro comment.  Add 'ptid'
      	parameter.  Use it to find thread to pass to
      	create_thread_event_object.
      	(emit_continue_event): Pass PTID down to
      	create_continue_event_object.
      	* python/py-event.h (py_get_event_thread): Declare.
      	(create_thread_event_object): Remove default from 'thread'
      	parameter.
      	* python/py-stopevent.c (create_stop_event_object): Use
      	py_get_event_thread.
      	* python/py-threadevent.c (get_event_thread): Rename to ...
      	(py_get_event_thread): ... this, make extern, add 'ptid' parameter
      	and use it to find the thread.
      	(create_thread_event_object): Assert that THREAD isn't null.
      	Don't find the event thread here.
      0e84db8c
    • GDB Administrator's avatar
      Automatic date update in version.in · 3d9afb67
      GDB Administrator authored
      3d9afb67
  3. 23 Aug, 2018 2 commits
    • Xavier Roirand's avatar
      Darwin: fix bad loop incrementation · 6354b651
      Xavier Roirand authored
      When reading symbols from the vector of oso files on Mac OS X
      Darwin, a previous commit introduce a change in the loop and add
      an increment at each loop iteration whereas this incrementation is
      not needed since the increment or set of the loop control variable
      is already done in the loop.
      
      gdb/ChangeLog:
      
      	* machoread.c (macho_symfile_read_all_oso): Remove uneeded
      	incrementation.
      
      Change-Id: I3a5a6deb4e9d834ee7d4217a62d90c2ffb7241bc
      6354b651
    • GDB Administrator's avatar
      Automatic date update in version.in · afd14728
      GDB Administrator authored
      afd14728
  4. 22 Aug, 2018 3 commits
  5. 21 Aug, 2018 1 commit
  6. 20 Aug, 2018 1 commit
  7. 19 Aug, 2018 1 commit
  8. 18 Aug, 2018 1 commit
  9. 17 Aug, 2018 3 commits
    • Tom Tromey's avatar
      Remove "repeat" argument from command_line_input · 84a39102
      Tom Tromey authored
      After the previous patch, all callers pass 0 as the repeat argument to
      command_line_input.  So, this patch removes it.
      
      2018-08-16  Tom Tromey  <tom@tromey.com>
      
      	* top.c (read_command_file): Update.
      	(command_line_input): Remove "repeat" argument.
      	* ada-lang.c (get_selections): Update.
      	* linespec.c (decode_line_2): Update.
      	* defs.h (command_line_input): Remove argument.
      	* cli/cli-script.c (read_next_line): Update.
      	* python/py-gdb-readline.c: Update.
      84a39102
    • Tom Tromey's avatar
      Fix use-after-free in number_or_range_parser · 5424be6a
      Tom Tromey authored
      -fsanitize=address showed a use-after-free in number_or_range_parser.
      
      The cause was that handle_line_of_input could stash the input into
      "saved_command_line", and then this could be freed by reentrant calls.
      
      This fixes the bug by preventing commands that are read by "commands"
      from being eligible for repeating.
      
      2018-08-17  Tom Tromey  <tom@tromey.com>
      
      	* cli/cli-script.c (read_next_line): Pass 0 as repeat argument to
      	command_line_input.
      5424be6a
    • GDB Administrator's avatar
      Automatic date update in version.in · 441cee92
      GDB Administrator authored
      441cee92
  10. 16 Aug, 2018 1 commit
  11. 15 Aug, 2018 1 commit
  12. 14 Aug, 2018 1 commit
  13. 13 Aug, 2018 1 commit
  14. 12 Aug, 2018 1 commit
  15. 11 Aug, 2018 1 commit
  16. 10 Aug, 2018 1 commit
  17. 09 Aug, 2018 1 commit
  18. 08 Aug, 2018 1 commit
  19. 07 Aug, 2018 1 commit
  20. 06 Aug, 2018 1 commit
  21. 05 Aug, 2018 1 commit
  22. 04 Aug, 2018 1 commit
  23. 03 Aug, 2018 1 commit
  24. 02 Aug, 2018 1 commit
  25. 01 Aug, 2018 1 commit
  26. 31 Jul, 2018 2 commits
    • Simon Marchi's avatar
      Remove struct keyword in range-based for loop · 599849be
      Simon Marchi authored
      PR gdb/23469
      Fix this with gcc 6.3.0:
      
      /home/simark/src/binutils-gdb/gdb/symfile.c: In function 'void set_objfile_default_section_offset(objfile*, const section_addr_info&, CORE_ADDR)':
      /home/simark/src/binutils-gdb/gdb/symfile.c:2114:14: error: types may not be defined in a for-range-declaration [-Werror]
         for (const struct other_sections *objf_sect : objf_addrs_sorted)
                    ^~~~~~
      gdb/ChangeLog:
      
      	* symfile.c (set_objfile_default_section_offset): Remove struct
      	keyword.
      
      (cherry picked from commit ff27d073)
      599849be
    • GDB Administrator's avatar
      Automatic date update in version.in · 31655631
      GDB Administrator authored
      31655631
  27. 30 Jul, 2018 1 commit
  28. 29 Jul, 2018 1 commit
  29. 28 Jul, 2018 1 commit