llvm dev - Mar 2006 - [LLVMdev] Re: Re: Re: Re: Re: New GCC4-based C/C++/ObjC front-end for LLVM

Evan Cheng wrote:
> Hi,
> 
> Here is the follow on patch for this problem. Please apply this from
> the top of the tree and rebuild.
With the patch from Chris and then the patch from you combined, the previous
error disappeared, but I get another error, reduced to this:

 ./cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mtune=pentiumpro
-auxbase-strip libgcc/./_clz.o -g -O2 -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version
-fPIC -fvisibility=hidden -o libgcc2.s
.....
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.

And this time the crash does not seem very misterious:


Program received signal SIGSEGV, Segmentation fault.
llvm::PATypeHolder::get (this=0x8) at Type.h:249
249       const Type *getForwardedType() const {

(gdb) where
#0  llvm::PATypeHolder::get (this=0x8) at Type.h:249
#1  0x08514f1f in llvm::PATypeHolder::operator llvm::Type* (this=0x8) at
AbstractTypeUser.h:140
#2  0x08514734 in llvm::Value::getType (this=0x0) at Value.h:76
#3  0x087a8f8a in ConstantStruct (this=0x8b28038, T=0x8b25730,
V=@0xbf8adef0)
    at /home/ghost/Work/llvm-cvs/lib/VMCore/Constants.cpp:275
#4  0x087e9058 in llvm::ConstantCreator<llvm::ConstantStruct,
llvm::StructType, std::vector<llvm::Constant*,
std::allocator<llvm::Constant*> > >::create (Ty=0x8b25730,
V=@0xbf8adef0)
    at /home/ghost/Work/llvm-cvs/lib/VMCore/Constants.cpp:531
#5  0x087e6eaf in (anonymous
namespace)::ValueMap<std::vector<llvm::Constant*,
std::allocator<llvm::Constant*> >, llvm::StructType,
llvm::ConstantStruct,
true>::getOrCreate (this=0x8af8060,
    Ty=0x8b25730, V=@0xbf8adef0)
at /home/ghost/Work/llvm-cvs/lib/VMCore/Constants.cpp:624
#6  0x087aa821 in llvm::ConstantStruct::get (Ty=0x8b25730, V=@0xbf8adef0)
    at /home/ghost/Work/llvm-cvs/lib/VMCore/Constants.cpp:994
#7  0x08714182 in llvm::DISerializer::Serialize (this=0x8b17834,
DD=0x8b54480)
    at /home/ghost/Work/llvm-cvs/lib/CodeGen/MachineDebugInfo.cpp:1204

The real problem is this:

#7  0x08714182 in llvm::DISerializer::Serialize (this=0x8b17834,
DD=0x8b54480)
    at /home/ghost/Work/llvm-cvs/lib/CodeGen/MachineDebugInfo.cpp:1204
1204      GV->setInitializer(ConstantStruct::get(Ty, Elements));
(gdb) p Elements[2]
$7 = (class llvm::Constant * const&) @0x8afbcf0: 0x0

This null pointer comes from line 274 of MachineDebugInfo.cpp:

  virtual void Apply(std::string &Field) {
    if (Field.empty()) {
      Elements.push_back(NULL);
    } else {
      Elements.push_back(SR.getString(Field));
    }
  }

Which comes from this:

  void TypeDesc::ApplyToFields(DIVisitor *Visitor) {
    DebugInfoDesc::ApplyToFields(Visitor);
  
    Visitor->Apply(Context);
    Visitor->Apply(Name);

Name is empty. Here's a minimal testcase that reproduces the crash:

   unsigned __clz_tab[] = {0};

just invoke cc1 as given in the beginning of this email with this text as
input. 

The problem is that llvm-debug.cpp:GetNodeName returns "" for the name
of
type of "__clz_tab", which is the root cause of the crash. I don't
know why
TYPE_NAME returns NULL, but I attach two possible patches.

First one just special cases arrays and integer variables. Again, don't know
why, but TYPE_NAME returns 0 even if 'tree' is a 'unsigned'
type.

Second one makes GetNodeName return non-empty string if it fails to
determine the name.

Neither patch is reasonable, but at least we know the problem. Now I get
crash in this (minimal) testcase:

   struct gcov_info
   {
      const char *filename;
   };

   struct gcov_info gcov_list;

This time the crash happens because DerivedTypeDesc corresponding to 
   DW_TAG_const_type<
         char*
   >
has no name. What follows from that is already explained above.

So, it looks either the snapshot is not in stable state, or there's
something seriously wrong with type name handling. At this point I gave up
on quickly fixing this, so I've applied the third attached patch to LLVM,
which "fixes" this issue completely.

After that, the frontend itself builds (the gcc directory), and "llvm-g++
-emit-llvm -S some_file.cpp") works. I did not do deep testing.

On the other hand, I still get segfaults when building libstdc++. I'll look
at them as soon as this "type name in debug info" is solved or
workarounded
either in LLVM CVS or in your frontend.

Sorry for the long email, this is basically a debugging log ;-)


- Volodya



-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-debug-patch1.diff
Type: text/x-diff
Size: 2063 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20060316/3e705068/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-debug-patch2.diff
Type: text/x-diff
Size: 328 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20060316/3e705068/attachment-0001.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-debug-patch3.diff
Type: text/x-diff
Size: 606 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20060316/3e705068/attachment-0002.diff>

Vladimir Prus wrote:
> So, it looks either the snapshot is not in stable state, or there's
> something seriously wrong with type name handling. At this point I gave up
> on quickly fixing this, so I've applied the third attached patch to
LLVM,
> which "fixes" this issue completely.
Ah, hell, as soon as I've send this email I've updated from CVS to find
that
the issue was fixed by Jim several hours after I reported the crash, by
making MachineDebugInfo don't check for empty name of type.
> After that, the frontend itself builds (the gcc directory), and
"llvm-g++
> -emit-llvm -S some_file.cpp") works. I did not do deep testing.
> 
> On the other hand, I still get segfaults when building libstdc++. I'll
> look at them as soon as this "type name in debug info" is solved
or
> workarounded either in LLVM CVS or in your frontend.
Here's what I get now:

/space/p2/ghost/build/llvm-frontend/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/compatibility.h:42:
internal compiler error: in make_decl_rtl, at varasm.c:1018


(gdb) where
#0  internal_error (gmsgid=0x8a02d8f "make_decl_rtl")
    at ../../2006-03-14-llvm-gcc-4/gcc/diagnostic.c:532
#1  0x082bf22f in fancy_abort (file=0x8a02d8f "make_decl_rtl",
line=1018,
    function=0x8a02d8f "make_decl_rtl")
at ../../2006-03-14-llvm-gcc-4/gcc/diagnostic.c:588
#2  0x084c0c5c in make_decl_rtl (decl=0xb7b9d618)
at ../../2006-03-14-llvm-gcc-4/gcc/varasm.c:1018
#3  0x084c8207 in assemble_alias (decl=0xb7b9d618, target=0xb698fe00)
    at ../../2006-03-14-llvm-gcc-4/gcc/varasm.c:4765
#4  0x084d05e6 in rest_of_decl_compilation (decl=0xb7b9d618, top_level=1,
at_end=0)
    at ../../2006-03-14-llvm-gcc-4/gcc/passes.c:204

Printing  decl in frame 2 gives:

(gdb) call debug_tree(decl)
 <function_decl 0xb7b9d618
_X_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv
    type <function_type 0xb7ab7e88
        type <void_type 0xb7ab5b40 void sizes-gimplified type_6 VOID
            align 8 symtab 146744576 alias set -1
            pointer_to_this <pointer_type 0xb7ab5bb8>>
        type_6 QI
        size <integer_cst 0xb7aa139c constant invariant 8>
        unit size <integer_cst 0xb7aa13b8 constant invariant 1>
        align 8 symtab 0 alias set -1
        arg-types <tree_list 0xb7aa1efc value <void_type 0xb7ab5b40
void>>
        pointer_to_this <pointer_type 0xb7121ca8>>
    public external asm-frame-size 0 no-static-chain decl_2 QI
file
/space/p2/ghost/build/llvm-frontend/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/compatibility.h
line 42 context<namespace_decl 0xb720a1e0 __gnu_internal> attributes
<tree_list 0xb7137bd0> initial <error_mark 0xb7aa12d8>
    chain <template_decl 0xb720aac8 __test_type>>


Preprocessed source goes by private email.

- Volodya

On Thu, 16 Mar 2006, Vladimir Prus wrote:
> Ah, hell, as soon as I've send this email I've updated from CVS to
find that
> the issue was fixed by Jim several hours after I reported the crash, by
> making MachineDebugInfo don't check for empty name of type.
:)
> Here's what I get now:
>
>
/space/p2/ghost/build/llvm-frontend/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/compatibility.h:42:
> internal compiler error: in make_decl_rtl, at varasm.c:1018
> (gdb) where
> Preprocessed source goes by private email.
Great, thanks for the info.  Please try this patch:

Index: varasm.c
==================================================================--- varasm.c  
(revision 112246)
+++ varasm.c    (working copy)
@@ -4759,6 +4759,13 @@ assemble_alias (tree decl, tree target)
      }
  # endif
  #endif
+
+  /* APPLE LOCAL begin LLVM */
+#ifdef ENABLE_LLVM
+  inform ("%JLLVM does not support aliases yet", decl);
+  return;
+#endif
+  /* APPLE LOCAL end LLVM */

    /* We must force creation of DECL_RTL for debug info generation, even though
       we don't use it here.  */


-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/