<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Use of fno-semantic-interposition leads to multiple addresses for globals."
href="https://bugs.llvm.org/show_bug.cgi?id=49715">49715</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Use of fno-semantic-interposition leads to multiple addresses for globals.
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>11.0
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>-New Bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>cfsteefel@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>htmldeveloper@gmail.com, llvm-bugs@lists.llvm.org, neeilans@live.com, richard-llvm@metafoo.co.uk
</td>
</tr></table>
<p>
<div>
<pre>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.
<span class="quote">> objdump -R main</span >
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 <a href="mailto:__libc_start_main@GLIBC_2.0">__libc_start_main@GLIBC_2.0</a>
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++</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>