This is the mail archive of the gdb-patches@sourceware.org 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]

Re: ping [Fwd: [RFC] User choice for multiply-defined symbols]


Markus,

> What I try to achieve with this patch is to do a complete lookup in all 
> object file(s) as well.  If this search finds more than one symbol "foo" 
> like seen in the following example, GDB should let the user choose, which
> one (or even more than one symbol) to use.
> 
> (gdb) break foo
> [0] cancel
> [1] all
> [2] foo at ../../../../src/gdb/testsuite/gdb.base/multiple_symbols_mod.c:5
> [3] foo at ../../../../src/gdb/testsuite/gdb.base/multiple_symbols.c:14
> 
> GDB's default behaviour isn't changed by the patch. User has to "set
> multiple-symbols ask" to invoke the search.  If > 1 symbols are found,
> the user is given the choice as seen above.

Sorry for the delay in getting back to you. I have been meaning to
get back to you for a couple of weeks now...

I think that we need to discuss what we want to happen at the user
level before we even delve into the implementation.  As far as I am
concerned, I would prefer if the semantics of the multiple-symbols
setting was preserved.  In other words, if the lookup finds several
possible locations, then it either uses them all, or raises an error
if only one location can be used.

That being said, I believe you are facing an issue that is very similar
in principle to handling overloading in Ada and Pascal. The references are:

    http://www.sourceware.org/ml/gdb-patches/2008-01/msg00008.html (Ada)
    http://www.sourceware.org/ml/gdb-patches/2008-09/msg00379.html (Pascal)

If we, as a group, decide that we should do the same for C, then
I suspect that the same approach will also apply to what you are
trying to solve.  The problem is, of course, that you face the same
hurdles.  One of them is to find a way to store enough information
in each actual breakpoint so that, when we have to re-evaluate it,
we know which one it was. I explain the problem with more details
in my answer to Pierre in the (Pascal) message. Unfortunately, we
haven't found a satisfactory solution yet - I'm offering a compromise,
but I definitely would like to have the OK of another Global Maintainer
before proceeding. This is a little controversial: We provide more
functionality that works most of the time, but it's not perfect, and
it's at the slight cost of a couple of compromises on the design.

-- 
Joel


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