Re: dbxout.c stabs output problem

[Jeffrey A Law <law at cygnus dot com>]

  In message <35A461CA.3D5E@axess.com>you write:
  > Jeffrey A Law wrote:
  > > 
  > > Something's definitely wrong, but without a testcase or more info about
  > > what's actually happening in dbxout.c, I can't guess what might be
  > > wrong,
  > 
  > This simple test:
  > 
  > #include <stdio.h>
  > 
  > int a[5] = {1, 2, 3, 4, 5};
  > char b[3] = {'a', 'b', 'c'};
  > 
  > int main(void)
  > {
  >   printf("%d", a[3]);
  >   return(0);
  > }
  > 
  > compiled with gcc -g -S (pgcc-2.90.27 980315 (egcs-1.0.2 release)
  > (386-ibm-os2)) gives me
  > 
  > .stabs "a:G31=ar0;0;4;1",32,0,3,0
  > .stabs "b:G32=ar0;0;2;2",32,0,4,0
  > 
  > in the output .s file (around lines 40 and 50).
Thanks.  Just in case anyone is interested -- you can't reproduce this
on a linux system because it uses a slightly more advanced stabs format.

It may be to your advantage to use the newer format -- if I remember
correctly the newer format is designd to allow the linker to strip out
some redundant information.  Define DBX_USE_BINCL in your tm.h file
to get the newer format.  I believe GNU ld and Sun ld know how to
interpret the new format and eliminate redundant information.  Other
linkers may handle BINCL too -- I don't know.


Anyway, back to your problem.


After looking at this, I'm unsure if the comments in dbxout.c are
correct anymore.  While we certainly shouldn't be seeing "ar0", it's
not clear that we should be strictly using "ar1" for the C arrays shown.


It appears that GCC is creating a new type for the array index type
which contains bounds information instead of using a "plain old int"
(see call to build_index_type in grokdeclarator).  This type gets
stored into TYPE_DOMAIN for the array's type.

We later get into dbxout.c::dbxout_type case ARRAY_TYPE:

      /* Output "a" followed by a range type definition
         for the index type of the array
         followed by a reference to the target-type.
         ar1;0;N;M for a C array of type M and size N+1.  */
      /* Check if a character string type, which in Chill is
         different from an array of characters.  */
      if (TYPE_STRING_FLAG (type) && use_gnu_debug_info_extensions)
        {
          have_used_extensions = 1;
          fprintf (asmfile, "@S;");
        }
      tem = TYPE_DOMAIN (type);
      if (tem == NULL)
        {
          fprintf (asmfile, "ar");
          dbxout_type_index (integer_type_node);
          fprintf (asmfile, ";0;-1;");
        }
      else
        {
          fprintf (asmfile, "a");
          dbxout_range_type (tem);
        }



Since TYPE_DOMAIN has been set, we'll call dbxout_range_type on the
value stored in TYPE_DOMAIN.  Which looks like:

dbxout_range_type (type)
     tree type;
{
  fprintf (asmfile, "r");
  if (TREE_TYPE (type))
    dbxout_type (TREE_TYPE (type), 0, 0);
  else if (TREE_CODE (type) != INTEGER_TYPE)
    dbxout_type (type, 0, 0); /* E.g. Pascal's ARRAY [BOOLEAN] of INTEGER */
  else
    {
      /* Traditionally, we made sure 'int' was type 1, and builtin types
         were defined to be sub-ranges of int.  Unfortunately, this
         does not allow us to distinguish true sub-ranges from integer
         types.  So, instead we define integer (non-sub-range) types as
         sub-ranges of themselves.  */
      dbxout_type_index (type);
    }

The type is an integer type, so we call dbxout_type_index.  Unfortunately
no index has yet been assigned to this type, so we get an index of zero.


I'm not sure how to fix this -- Jim's the expert on dbxout.c, so maybe
he has some ideas (I've cc'd him on this message).

jeff