This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 0/4] Non-contiguous address range bug fixes / improvements
- From: Kevin Buettner <kevinb at redhat dot com>
- To: Tom Tromey <tom at tromey dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 3 Jul 2019 13:10:13 -0700
- Subject: Re: [PATCH 0/4] Non-contiguous address range bug fixes / improvements
- References: <20190608195434.26512-1-kevinb@redhat.com> <87tvcc5kf5.fsf@tromey.com>
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