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

Vladimir Prus ghost at cs.msu.su
Thu Mar 16 03:05:51 PST 2006


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>


More information about the llvm-dev mailing list