Re: RFC: branching for GDB 7.11 soon? (possibly Wed)

[Keith Seitz <keiths at redhat dot com>]

On 01/31/2016 07:06 PM, Joel Brobecker wrote:
> 
> PR19474 "break LINE_NUM" set breakpoint on file other than current source file
> (suggest Keith?)

> At the moment, I would be hesitant to branch before we first
> analyze what would be required to fix PR19474 ("break LINE_NUM").
> But if we're confident that it can be fairly safely fixed on
> the branch, I don't see any other issue blocking for branching,
> which I would then propose to be doing sometime early Wed.

I started looking at this last week, and I have an analysis of the
problems. It all basically boils down to: we cannot (reliably) win in
this situation.

Reminder of the situation from the bug: We have the two symtabs
/home/keiths/tmp/f.c and /home/keiths/tmp/foo/f.c. This later symtab
exists on the disk, though, as /home/keiths/tmp/bar/f.c.

In create_sals_line_offset, we get the current source symtab and then
search for all symtabs matching that name. This is required because we
may have multiple symtabs for the same source file. [See
expand-psymtabs.exp for an example.]

When we go looking for the psymtab, we call psymtab_to_fullname, which
uses find_and_open_source to search the source path, which includes
/home/keiths/tmp/foo (the CDIR) and CWD.

This last bit is the problem. If the user's CWD is /home/keiths/tmp,
openp will return that /home/keiths/tmp/f.c is a match for the requested
symtab filename, /home/keiths/tmp/foo/f.c. This is clearly incorrect.
The two source files are /not/ the same, but find_and_open_source
returns that it found the foo/f.c symtab even when it didn't. [When sal
conversion is complete, gdb will look up the symtab name by PC, it then
finds the "correct" symtab for reporting during "info break."]

So, yes, this bug can be worked around by NOT having your CWD set to
/home/keiths/tmp. A simple "cd .." will "fix" things. Ouch!

Aside: It seems to me that instead of doing basename searches and using
CWD, this whole thing should really do/support directory mappings, e.g.,
the user can say, "whenever you see /home/keiths/tmp/foo, look instead
in /home/keiths/tmp/bar." But I don't think that really addresses the
problem at hand.

The only solution I've come up with is changing the whole API so that in
this specific case (searching for a known symtab), we reject searching
the source path. As you can imagine, that could open up an entirely new
"can of worms." [And that change would be quite intrusive.]

Like Yao, I'm not entirely sure what to do here yet.

Keith