[llvm-bugs] [Bug 24486] New: [MC] Clang integrated-as doesn't support local aliases to global variables (GNU as does).

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=24486

            Bug ID: 24486
           Summary: [MC] Clang integrated-as doesn't support local aliases
                    to global variables (GNU as does).
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: m.ostapenko at partner.samsung.com
                CC: llvm-bugs at lists.llvm.org, rafael.espindola at gmail.com,
                    y.gribov at samsung.com
    Classification: Unclassified

Trying to resolve this
https://code.google.com/p/address-sanitizer/issues/detail?id=398 issue, I found
out, that clang integrated-as doesn't support local aliases to global variables
(GNU assembler does). Consider the following testcase:

$ cat test.s

    .data
    .global foo
foo:
    .long
bar = foo
    .long    bar

$ clang -c tmp.s && readelf -r tmp.o

Relocation section '.rela.data' at offset 0x90 contains 1 entries:
  Offset          Info           Type           Sym. Value    Sym. Name +
Addend
000000000000  00020000000a R_X86_64_32       0000000000000000 foo + 0

$ gcc -c tmp.s && readelf -r tmp.o

Relocation section '.rela.data' at offset 0x318 contains 1 entries:
  Offset          Info           Type           Sym. Value    Sym. Name +
Addend
000000000000  00020000000a R_X86_64_32       0000000000000000 .data + 0

While GNU as generates relocation for "bar", addressing local .data storage,
clang integrated as addresses it to its aliasee, global variable "foo", that
might be located in completely different place (e.g. when shared library and
executable define the same global variable).

After some investigation, I found out, that the code responsible for Sym. Name
entry in '.rela.data' section located here:

$ cat lib/MC/MCExpr.cpp

bool MCExpr::evaluateAsRelocatableImpl(MCValue &Res, const MCAssembler *Asm,
                                       const MCAsmLayout *Layout,
                                       const MCFixup *Fixup,
                                       const SectionAddrMap *Addrs,
                                       bool InSet) const {
.........................

  case SymbolRef: {
    const MCSymbolRefExpr *SRE = cast<MCSymbolRefExpr>(this);
    const MCSymbol &Sym = SRE->getSymbol();

    // Evaluate recursively if this is a variable.
    if (Sym.isVariable() && SRE->getKind() == MCSymbolRefExpr::VK_None &&
        canExpand(Sym, Asm, InSet)) {
      bool IsMachO = SRE->hasSubsectionsViaSymbols();
      if (Sym.getVariableValue()->evaluateAsRelocatableImpl(
              Res, Asm, Layout, Fixup, Addrs, InSet || IsMachO)) {
........................
  } 

Is this the right place to fix the issue? Could someone more familiar with
Clang/LLVM code base help me to cook proper fix?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150818/2124f358/attachment-0001.html>