This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFC] decode_line_1 suggestion (problem with "list" command)


Hello,

We have a small problem with the list command. The following example
uses Ada, but I think the same kind of problem can occur in C++ as well.
The problem occurs when we use generics (templates in C++):

        generic
        function Gen1 return Integer;

        function Gen1 return Integer is
        begin
           return 0;
        end Gen1;

When we instantiate the generics more than once, vis:

        with Gen1;
        procedure Foo is
           function F1 is new Gen1;
           function F2 is new Gen1;
        
           X : Integer;
        begin
           X := F1;
        end Foo;

The compiler creates the code for each instantiation (which means
the code is duplicated). As a side effect, the line number information
is also duplicated.

The problem appears when the user tries to set a breakpoint inside one
of the generic instantiations using the FILE:LINE syntax. If the
location points inside a generic, and the generic has been instantiated
more than once, then the location is ambiguous.

For "break" commands, we present a multiple-choice question to the user,
asking him which instantiation he meant, like this:

        (gdb) break gen1.adb:3
        [0] cancel
        [1] all
        [2] gdb1.f1
        [3] gdb1.f2

But we recently noticed that the same question was asked when the user
used a "list" command, which is not friendly:

        (gdb) list gen1.adb:1
        [0] cancel
        [1] all
        [2] gdb1.f1
        [3] gdb1.f2

In our opinion, GDB should not be asking the user which instantiation
because it's not going to have any impact on the result. And besides,
a user could rightly argue that the location is not ambiguous in the
context of the "list" command. I think the problem is only with the
FILE:LINE syntax, and that GDB should keep presenting the question
for ambiguous locations using other location formats (like locations
using the name of a function which is overloaded).

Looking at GDB's code, I see that the location evaluation is for both
"break" and "list" are the same: decode_line_1(). 

I'd like to make a small change, but since we are planning on
integrating our Ada mode to the master tree, I wanted to make sure that
this change was OK with the maintainers first. And I also think that
this will be of interest to the C++ maintainer too.

The most reasonable approach I see is to add a new parameter to
decode_line_1 (say source_location_only) which would be used to
determine whether we should present the choice to the user in the case
above or not. Would that seem a reasonable approach?

Thanks,
-- 
Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]