[llvm-bugs] [Bug 49715] New: Use of fno-semantic-interposition leads to multiple addresses for globals.

[via llvm-bugs]

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

            Bug ID: 49715
           Summary: Use of fno-semantic-interposition leads to multiple
                    addresses for globals.
           Product: clang
           Version: 11.0
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: cfsteefel at gmail.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org,
                    neeilans at live.com, richard-llvm at metafoo.co.uk

With the use of fno-semantic-interposition, it is possible for a shared library
(PIC)  and an executable (not PIC) to disagree on the address of a global
variable. The global variable must be considered to be Copy relocatable in the
executable in order for the issue to appear. Within the shared library, the
pointer will be considered to be pointing into the data.relro segment of the
shared library (pre relocation pointer), while the main executable will see the
pointer as pointing to the BSS section (relocated pointer). 

The following example demonstrates the issue:

lib.h:
struct Foo final {
   constexpr Foo(int x_, int y_) : x(x_), y(y_) {}
   int getX() const { return x; }
   int getY() const { return y; }
private:
   int const x;
   int const y;
};

extern const Foo foo;

extern void f(const Foo *);

lib.cc:
#include "lib.h"
#include <cassert>

const Foo foo(1, 2);

void f(const Foo *f) {
   assert(&foo == f);
}

main.cc:
#include "lib.h"

int
main()
{
   f(&foo);
}

Used repro steps options:
clang++ -fno-semantic-interposition -std=gnu++17 -g  -c -o main.o main.cc
clang++ -fno-semantic-interposition -std=gnu++17 -g -fPIC -c -o lib.o lib.cc
clang++ -o liblib.so lib.o -shared
clang++  -o main main.o liblib.so
env LD_LIBRARY_PATH=. ./main


Objdump shows that foo is a copy relocation here.
> objdump -R main

main:     file format elf32-i386

DYNAMIC RELOCATION RECORDS
OFFSET   TYPE              VALUE
08049ffc R_386_GLOB_DAT    __gmon_start__
0804a01c R_386_COPY        foo
0804a00c R_386_JUMP_SLOT   __libc_start_main at GLIBC_2.0
0804a010 R_386_JUMP_SLOT   _Z1fPK3Foo



Removing -fno-semantic-interposition from the compilation of lib.cc avoids the
issue. Adding fPIC to the compilation of main.cc removes the copy relocation,
and also avoids the issue.
The issue is also seen in an equivalent 64 bit environment.
Clang is version 11.0.0 

The issue does not occur if clang++ is replaced by g++

-- 
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/20210324/4c6b4494/attachment.html>