[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/15228] New: copy relocations against protected symbols should be
From: |
luto at mit dot edu |
Subject: |
[Bug ld/15228] New: copy relocations against protected symbols should be disallowed |
Date: |
Tue, 05 Mar 2013 00:53:59 +0000 |
http://sourceware.org/bugzilla/show_bug.cgi?id=15228
Bug #: 15228
Summary: copy relocations against protected symbols should be
disallowed
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: address@hidden
ReportedBy: address@hidden
Classification: Unclassified
Take this code:
-- begin lib.cc --
struct A
{
A() : x(1) {}
int x;
};
__attribute__((visibility("protected"))) A a;
-- end lib.cc --
--begin main.cc--
struct A
{
A() : x(1) {}
int x;
};
extern A a;
extern "C" void abort(void);
int main()
{
if (a.x != 1)
abort();
}
--end main.cc--
and build it with:
$ g++ -shared -fPIC -o lib.so lib.cc
$ g++ lib.so main.cc
ld sees a protected defined object called a of size 4 in lib.so and an
undefined object called a in main.o. It helpfully generates a copy relocation.
The resulting code cannot possibly work, and, in fact, it aborts. Everything
works fine with -fPIE.
IMO it would be much better to fail to link than to produce a binary that ld.so
is happy to load (maybe that's an ld bug) but that is more or less guaranteed
to execute incorrectly.
(FWIW, Windows has solved this problem using dllimport for many years, but
that's another story.)
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Bug ld/15228] New: copy relocations against protected symbols should be disallowed,
luto at mit dot edu <=