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

[Matt Rice <ratmice@gmail.com>]

On Sun, Oct 17, 2010 at 1:12 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Wed, 06 Oct 2010 15:12:06 +0200, Matt Rice wrote:
>> what I mean is that 'break' is not related to the current language,
>> but the language which we want to be the current language
>> when the breakpoint is hit.  and so 'set language' to use language
>> specific breakpoints is arguably wrong because the current language
>> may not be the language of the breakpoint we want set.
>
> OK, I understand that Obj-C is special that it (a) is mixed with C/C++ and
> even possibly having C/C++ main(), (b) requiring Obj-C specific support to
> just figure out where to place a breakpoint.
>
> That `objc:' breakpoint prefix etc. could be nice but a more conservative
> change IMO also makes sense.  I can imagine it could be inconvenient for Obj-C
> development (which I do not know myself, though).

I tend to agree, with the conservative approach,
requiring objc: sometimes could lead to an inconsistent user experience
I prefer this approach because of the minimal user impact, yet we get
the bulk of objc_decode
out of the way of non-objc users.

>> doesn't seem as though reading language symfiles frobs the current
>> language afaict.
>
> It really does not.
>
>
> +  set_language_has_cu_loaded(subfile->language);
>
> here should be a space: `...loaded (subfile->...'

k, will fix that

> +/* A mask for languages that want to enable specific behaviours if (not when)
> +   a compilation unit of that language has been loaded. */
> +#define CU_LOADED_C_LANG_MASK          0x1 << 0
> +#define CU_LOADED_CPLUS_LANG_MASK      0x1 << 1
>
> Do I miss something why don't you use enum language like (1 << language_objc)?
> nr_languages == 14 so it fits fine into a bitmask.  BTW such #define right
> hand sides should be in parentheses (for operator priority surprises during
> their use).

before i spin a new patch, lets resolve this, the reason I used a
define instead of an enum
was because I vaguely reember weird differences wrt c and c++ enum use
as numerical values.
 Not sure if this case is actually hit by that, I just figured that
define was relatively future-proof,

if a bit ugly, i should probably actually try it with c++.
I definitely prefer enum to what i did here.  so yeah, there was a
reason but its possibly
irrelevent and/or unecessary.

> +static unsigned int cu_languages_loaded_mask;
>
> One can imagine this mask may (possibly in the future) modify user-visible
> behavior due to a different code paths being executed due to it - which is
> also its purpose.
>
> Loading program A, kill, loading program B would behave differently than just
> loading program B with fresh GDB.
>
> I would place such mask into `struct objfile'.  Checking its content then
> means iterating ALL_OBJFILES but I would find it acceptable.  (Some
> accelerations of such scheme are also possible - when performance is a goal of
> this patch anyway.)  This would make the GDB behavior more deterministic IMO.

ahh, I had totally spaced on this and the multi-process impact of this
change, thanks
will look into this.

> +unsigned int
> +language_has_cu_loaded (enum language lang)
> +{
> +  unsigned int lang_mask = mask_for_language (lang);
> +  return cu_languages_loaded_mask & lang_mask;
> +}
>
> As it returns boolean it should be just `int' and I would make it normalized
> to 0-or-1.

k