[0/4] Non-contiguous address range bug fixes / improvements

Message ID 20190608195434.26512-1-kevinb@redhat.com
Headers show
Series
  • Non-contiguous address range bug fixes / improvements
Related show

Message

Kevin Buettner June 8, 2019, 7:54 p.m.
This four part series fixes some bugs associated with GDB's non-contiguous
address range support.

Kevin Buettner (4):
  Prefer symtab symbol over minsym for function names in non-contiguous
    blocks
  dwarf2-frame.c: Fix FDE processing bug involving non-contiguous ranges
  Allow display of negative offsets in print_address_symbolic()
  Improve test gdb.dwarf2/dw2-ranges-func.exp

 gdb/dwarf2-frame.c                            |   8 +-
 gdb/printcmd.c                                |   8 +-
 gdb/stack.c                                   |  15 +-
 ...anges-func.c => dw2-ranges-func-hi-cold.c} |  44 +-
 .../gdb.dwarf2/dw2-ranges-func-lo-cold.c      |  82 +++
 gdb/testsuite/gdb.dwarf2/dw2-ranges-func.exp  | 694 ++++++++++--------
 6 files changed, 505 insertions(+), 346 deletions(-)
 rename gdb/testsuite/gdb.dwarf2/{dw2-ranges-func.c => dw2-ranges-func-hi-cold.c} (85%)
 create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-ranges-func-lo-cold.c

-- 
2.21.0

Comments

Tom Tromey June 26, 2019, 5:24 p.m. | #1
>>>>> "Kevin" == Kevin Buettner <kevinb@redhat.com> writes:


Kevin> This four part series fixes some bugs associated with GDB's non-contiguous
Kevin> address range support.

This is not really related to your patches, but since you have been
working in this area, I thought I'd ask.

I ran into a case where gdb will mis-report a breakpoint location in a
certain situation (that is, "info b" will show something odd for the
source location).  After debugging for a while, my theory is that the
problem occurs because the executable has non-contiguous address ranges.

In particular, find_pc_sect_line is written to first find the symtab
with the smallest overall range that encloses the PC, and then to find a
matching symbol in the symtab.  But, with non-contiguous ranges, this
can yield a sub-optimal result -- because the overall range of a symtab
not longer really says anything about whether it holds the best symbol.

Have you seen anything like this?  (I guess not since I'd imagine you'd
have written a patch ;-)

I was thinking perhaps the best fix would be to search the blockvectors
for a definitively enclosing block.  I wonder what you think.

thanks,
Tom
Kevin Buettner July 3, 2019, 8:10 p.m. | #2
On Wed, 26 Jun 2019 11:24:46 -0600
Tom Tromey <tom@tromey.com> wrote:

> >>>>> "Kevin" == Kevin Buettner <kevinb@redhat.com> writes:  

> 

> Kevin> This four part series fixes some bugs associated with GDB's non-contiguous

> Kevin> address range support.  

> 

> This is not really related to your patches, but since you have been

> working in this area, I thought I'd ask.

> 

> I ran into a case where gdb will mis-report a breakpoint location in a

> certain situation (that is, "info b" will show something odd for the

> source location).  After debugging for a while, my theory is that the

> problem occurs because the executable has non-contiguous address ranges.

> 

> In particular, find_pc_sect_line is written to first find the symtab

> with the smallest overall range that encloses the PC, and then to find a

> matching symbol in the symtab.  But, with non-contiguous ranges, this

> can yield a sub-optimal result -- because the overall range of a symtab

> not longer really says anything about whether it holds the best symbol.

> 

> Have you seen anything like this?  (I guess not since I'd imagine you'd

> have written a patch ;-)

> 

> I was thinking perhaps the best fix would be to search the blockvectors

> for a definitively enclosing block.  I wonder what you think.


Hi Tom,

I hadn't encountered this (yet), but I have no doubt that there are still
some things to be fixed.

I'll play around with my test case to see if I can reproduce the behavior
that you've described.

Kevin