[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gdb-bugs
Subject:    Oddity in generic_use_struct_convention
From:       "Donn Terry" <donnte () microsoft ! com>
Date:       2002-10-14 20:03:00
Message-ID: FE465D8F724E3F4F811D067203A214AE067386C0 () red-msg-08 ! redmond ! corp ! microsoft ! com
[Download RAW message or body]

In generic_use_struct_convention(), the code checks for gcc_p having the
value of exactly 1.   Inferring from the name (_p), this is intended as
a boolean type.

In valops.c, there's the following code:

#ifdef CARE_IF_GCC
  {
    struct block *b = block_for_pc (funaddr);
    /* If compiled without -g, assume GCC 2.  */
    using_gcc = (b == NULL ? 2 : BLOCK_GCC_COMPILED (b));
  }
#else
  /* If we don't care if we're using gcc or not on this system,
     then default to 2.  Note that there appears to be NO code
     that actually sets up BLOCK_GCC_COMPILED (gcc_compile_flag)
     so this is all pretty much meaningless anyway, but it
     breaks the regressions (callfunc).  */
  using_gcc = 2;
#endif

  /* Are we returning a value using a structure return or a normal
     value return? */

  struct_return = using_struct_return (function, funaddr, value_type,
                                       using_gcc);
---
Note that using_gcc can be 2 (==don't care) at that point.  Following
down
thru using_struct_return(), the 2 gets passed on to 
generic_use_struct_convention (via the macro USE_STRUCT_CONVENTION),
presumably violating its assumptions about gcc_p being "boolean".  
(As far as I can tell, the case when it is 2 should be treated as
"true", which is not the case.)

A version of USE_STRUCT_CONVENTION that converts its first argument to
"boolean"
(a zero/nonzero test) seems to work for me (while passing the 2 thru did
not),
but that's probably not the right long-term fix.

Donn



[prev in list] [next in list] [prev in thread] [next in thread]