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

[Matt Rice <ratmice at gmail dot com>]

On Tue, Oct 5, 2010 at 4:35 PM, Matt Rice <ratmice@gmail.com> wrote:
> On Tue, Oct 5, 2010 at 4:31 PM, Michael Snyder <msnyder@vmware.com> wrote:
>> Matt Rice wrote:
>>>
>>> this makes it so that a flag is set if either an objective-c
>>> compilation unit is found,
>>> or the user goes 'set language objective-c' in the case where debug
>>> symbols are absent.
>>>
>>> 2010-10-05 ?Matt Rice ?<ratmice@gmail.com>
>>>
>>> ? ? ? ?* defs.h: Add comment.
>>> ? ? ? ?* dwarf2read.c (set_cu_language): Notice that a language has been
>>> ? ? ? ?seen.
>>> ? ? ? ?* language.c (set_language): Ditto.
>>> ? ? ? ?(mask_for_language, language_has_cu_loaded): New Functions.
>>> ? ? ? ?(set_language_has_cu_loaded): Ditto.
>>> ? ? ? ?* language.h: Declare new functions.
>>> ? ? ? ?* linespec.c (decode_line_1): Don't lookup objective-c methods
>>> ? ? ? ?unless objective-c has been seen.
>>
>> Hi Matt,
>>
>> Do you have a ?copyright assignment?
>
> Yeah, I do
>
> and I should have probably noted that this is a change of behaviour
> so its kind of an RFC, and I didn't think about stabs, so w/ this they
> probably require 'set language objective-c' 'set language auto' should
> restore the old behaviour
>
> waiting on the testsuite to run, but it looks like gdb.objc/nondebug.exp
> is going to require 'set language objective-c'.
>

attached is a new patch, the old one had some typos/pasteos in
comments, and i noticed
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?)

added a NEWS entry which at least explains the current impact of the change.
which may or may not be acceptable.

I asked on the gnustep-dev list a while ago about removing this
feature all together, they weren't opposed to replacing it with a
different but similar feature,
so they're probably not opposed to keeping the feature but having to
manually enable it if it cannot be lazily enabled.

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


another patch here which i'll look into tomorrow to see whatever
happened with it,
might be helpful in squaring out support for other debug info formats
also probably looking for .m sources.
http://sourceware.org/ml/gdb-patches/2004-08/msg00138.html

the impetus for this is that Objective-c matches normal c functions as methods,
so when you set a breakpoint on a c-function it tries to match it to
an objective-c method and churns through all the symbols, then finally
falls back to looking for a c function.


-PASS: gdb.cp/psmang.exp: break s::method2
+FAIL: gdb.cp/psmang.exp: break s::method2 (got interactive prompt)

-FAIL: gdb.threads/attachstop-mt.exp: attach1, post-gdb sanity check
of the sleeping state - Red Hat BZ 197584
+PASS: gdb.threads/attachstop-mt.exp: attach1, post-gdb sanity check
of the sleeping state - Red Hat BZ 197584

at least it broke even.

Attachment: gdb-lang-objc.diff
Description: Binary data