Re: gdb.objc/objcdecode.exp test error..

[Joel Brobecker <brobecker@adacore.com>]

> I tend to think that the results should depend a bit on the current
> language.

I agree.

> If we did this, then "break create" in C mode would only find the C
> function of that name, but the ObjC code would be free to make
> "break create" do whatever searching ObjC programmers deem reasonable.

Just being the devil's advocate:

The issue with this approach, I suspect, is that ObjC developers where
used to be able to do ObjC debugging while in using the "c" language.
It seems to be an excessive convenience at first sight, but I understand
a bit the need for it, because I would imagine that a typical ObjC
program is a mix of C and ObjC, not pure ObjC. So if you switch
languages because you switch frames, sometimes "break foo" will "work"
(when the current language is "objc", and sometimes it won't (when
the language is c/c++, etc).  The definition of "work" is currently
meant to match the current ObjC developer expectation.

I've already said that I think that the current feature is wrong and
should be removed.  But perhaps we can find a compromise where "break
foo" now only matches "foo" when in C language, and extend the C
language support to provide a way of specifying all foo ObjC methods.

More generally speaking, I think it's OK to provide convenience
access to non-C language features, but it should not be at the expense
of the C language support.

-- 
Joel