This is an archive of the discontinued LLVM Phabricator instance.

[mips] Save a copy of MipsABIInfo in the MipsTargetStreamer to escape a dangling pointer
ClosedPublic

Authored by atanasyan on Sep 11 2015, 8:43 AM.

Details

Summary

The MipsTargetELFStreamer can receive ABI info from many sources. For example, from the MipsAsmParser instance. Lifetime of the MipsAsmParser can be shorter than MipsTargetELFStreamer's lifetime. In that case we get a dangling pointer to MipsABIInfo.

Diff Detail

Repository
rL LLVM

Event Timeline

atanasyan updated this revision to Diff 34551.Sep 11 2015, 8:43 AM
atanasyan retitled this revision from to [mips] Save a copy of MipsABIInfo in the MipsTargetStreamer to escape a dangling pointer.
atanasyan updated this object.
atanasyan added a reviewer: dsanders.
atanasyan set the repository for this revision to rL LLVM.
atanasyan added a subscriber: llvm-commits.
dsanders edited edge metadata.Sep 11 2015, 9:15 AM

I think I can probably guess (direct object emission?) but can you tell me what situation causes MipsELFTargetStreamer to out live MipsAsmParser?

I think I can probably guess (direct object emission?) but can you tell me what situation causes MipsELFTargetStreamer to out live MipsAsmParser?

The following test case reproduces the problem. I am going to commit it to the clang repository after this fix.

// REQUIRES: mips-registered-target                                                                                                                                                                                
// RUN: %clang_cc1 -triple mips-linux-gnu -emit-obj -o - %s | \                                                                                                                                                    
// RUN:   llvm-readobj -h - | FileCheck %s                                                                                                                                                                           
                                                                                                                                                                                                                   
// CHECK: EF_MIPS_ABI_O32                                                                                                                                                                                          
                                                                                                                                                                                                                   
__asm__(                                                                                                                                                                                                           
"bar:\n"                                                                                                                                                                                                           
"  nop\n"                                                                                                                                                                                                          
);                                                                                                                                                                                                                 
                                                                                                                                                                                                                   
void foo() {}
dsanders accepted this revision.Sep 14 2015, 2:10 AM
dsanders edited edge metadata.

Hmm. MipsAsmPrinter is supposed to be delivering the ABI information for that path and it looks like it's still alive since AsmPrinter::doFinalization() is in the call stack at the point of the bad read. However, valgrind is clearly showing the invalid read occurred in memory belonging to a dead MipsAsmParser.

The MipsAsmParser presumably only exists because it's needed to parse the asm statement. My guess is that what's happening is MipsAsmPrinter delivers the ABI information as it's supposed to, then MipsAsmParser is constructed and substitutes its own MipsABIInfo pointer. MipsAsmParser is then destroyed, leaving a dangling pointer. Meanwhile, the pointer to MipsAsmPrinter's MipsABIInfo remains valid.

The target triples project will be able to solve this nicely since we'll be able to consult the longer-lived TargetTuple but we shouldn't make this fix depend on that. This patch seems reasonable in the mean time. LGTM

This revision is now accepted and ready to land.Sep 14 2015, 2:10 AM
This revision was automatically updated to reflect the committed changes.