Re: disable objective-c stuff when theres no objective-c cu.

[Matt Rice <ratmice@gmail.com>]

On Wed, Oct 6, 2010 at 1:51 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Wed, 06 Oct 2010 04:30:33 +0200, Matt Rice wrote:
>> that we can lessen the impact by checking for is_objc_method, or for
>> objective-c compilation units. (is_objc_method doesn't neccesarily
>> affect future lookups should it call set_language_has_cu_loaded?)
>
> Wouldn't be enough to replace the bitmask just by?
>        if (current_language->la_language == language_objc)

objective-c uses mixed compilation units possibly more than most other
languages,
e.g. objc++ can contain c++ and objc compilation units in the same file
which we don't emit dwarf for yet, but there has been some recent work for lto
I was watching which looks to make this possibly fixable, so basing it
off of 'current_language'
means you may have to either use the explicit long form (discussed in
news), or conversely
it is possible that the short form would be able to both work/not work
at different times when debugging

currently you are able to set a breakpoint from languages regardless
of the current one
everywhere else in the decode_line_1 path, e.g. i can set a c++ one
with the current language objective-c.
and vice versa (well maybe not the decode_variable line with
'(implicit this->)foo'

personally I think that having break work consistently across
compilation units is nice,
and tried to get somewhere in the middle between working all the time everywhere
and working based on current language.

>> here is when gcc started to emit DW_LANG_ObjC, maybe we could fall
>> back to source files with the .m extension.
>> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01515.html
>
> For current_language it works even without DW_LANG_ObjC due to:
>        init_filename_language_table (void)
>              add_filename_language (".m", language_objc);

maybe the dwarf2read call to set_language_has_cu_loaded is redundant
then since i added the call from set_language