[Bug gold/15662] New: gold (powerpc) internal error in do_relax() at gold/output.h:436
http://sourceware.org/bugzilla/show_bug.cgi?id=15662
Bug ID: 15662
Summary: gold (powerpc) internal error in do_relax() at
gold/output.h:436
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: gold
Assignee: ian at airs dot com
Reporter: jingyuuiuc at gmail dot com
CC: ccoutant at google dot com
I found a few link time failures, reporting
internal error in set_current_data_size_for_child, at
/usr/local/home/jingyu/opensource/binutils_trunk/src/gold/output.h:436
I am using top of trunk gold.
I investigated the failure and found that the error happens when
set_current_data_size_for_child is called through
this->rel_->add_relative(elfcpp::R_POWERPC_RELATIVE, this, off, to);
through
Target_powerpc::do_relax().
I notice that the data size for the failing object has been changed a
few times during relaxation. Every time before it is updated,
this->is_data_size_valid_ will be set to false. And after data size is
updated, is_data_size_valid_ will be set to true. However, when the
data size is updated through add_relative, the flag
is_data_size_valid_ is not set to false beforehand, which triggers the
assertion failure. I think it is a bug.
To verify my thought, I made a patch on powerpc.cc, though I am not sure it is
the proper way to fix. With the patch, the failing tests pass linking.
Index: powerpc.cc
===
RCS file: /cvs/src/src/gold/powerpc.cc,v
retrieving revision 1.91
diff -r1.91 powerpc.cc
2631a2632
> this->brlt_section_->reset_rel_data_size();
2638a2640
> this->brlt_section_->finalize_rel_data_size();
3015a3018,3029
> void
> reset_rel_data_size()
> {
> this->rel_->reset_data_size();
> }
>
> void
> finalize_rel_data_size()
> {
> this->rel_->finalize_data_size();
> }
>
Is the patch the proper way to fix the bug? Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/16937] New: aarch64: issue about executable exporting TLS class static member variable
https://sourceware.org/bugzilla/show_bug.cgi?id=16937
Bug ID: 16937
Summary: aarch64: issue about executable exporting TLS class
static member variable
Product: binutils
Version: 2.25 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: jingyuuiuc at gmail dot com
I have a piece of code behaves wrong on aarch64. The scenario is that both
executable and shared library define a TLS class static member variable.
On aarch64, the executable exports the symbol to dynamic symbol stable
with GLOBAL DEFAULT attribute. When shared library is dlopened, dynamic loader
finds the symbol in executable's symbol table and binds to it. Thus
both dynamic library and executable share the same copy of this
variable, which is wrong.
It's generally not expected that the linker will export a symbol in the
executable's dynamic symbol table unless it sees a reference from a shared
library.
$ g++ var_exe.cc -ldl -o var
$ g++ -shared -fPIC var_l.cc -o libvar1.so
$ g++ -shared -fPIC var_l.cc -o libvar2.so
On aarch64:
$ ./var
exe: live += 5
exe: live = 5
Calling libentry in ./libvar1.so...
lib: live += 3
lib: live = 8
Calling libentry in ./libvar2.so...
lib: live += 3
lib: live = 11
$ readelf --dyn-syms -W var | grep _ZN3var4liveE
11: 4 TLS GLOBAL DEFAULT 18 _ZN3var4liveE
$ readelf --dyn-syms -W libvar1.so | grep _ZN3var4liveE
16: 4 TLS GLOBAL DEFAULT 16 _ZN3var4liveE
$ readelf --dyn-syms -W libvar2.so | grep _ZN3var4liveE
16: 4 TLS GLOBAL DEFAULT 16 _ZN3var4liveE
On x86:
$ ./var
exe: live += 5
exe: live = 5
Calling libentry in ./libvar1.so...
lib: live += 3
lib: live = 3
Calling libentry in ./libvar2.so...
lib: live += 3
lib: live = 3
$ readelf --dyn-syms -W var | grep _ZN3var4liveE
$ readelf --dyn-syms -W libvar1.so | grep _ZN3var4liveE
13: 4 TLS GLOBAL DEFAULT 16 _ZN3var4liveE
$ readelf --dyn-syms -W libvar2.so | grep _ZN3var4liveE
13: 4 TLS GLOBAL DEFAULT 16 _ZN3var4liveE
var.h:
#include
class var{
public:
var(){};
static void output(const char* prefix) {
printf("%s: live = %d\n", prefix, live);
};
static void inc(const char* prefix, int i) {
printf("%s: live += %d\n", prefix, i);
live += i;
};
private:
static __thread int live;
};
var_l.cc:===
#include
#include
#include "var.h"
__thread int var::live=0;
extern "C" void libentry() {
var libvar;
libvar.inc("lib", 3);
libvar.output("lib");
}
var_exe.cc:=
#include
#include
#include
#include "var.h"
__thread int var::live=0;
void* load_lib_and_call(const char* libname) {
void* handle = dlopen(libname, RTLD_LOCAL | RTLD_NOW);
if (handle == NULL) {
printf("Can not open shared library %s\n", libname);
return 0;
}
typedef void (*lib_fun_t)();
lib_fun_t lib_entry_ = (lib_fun_t)(dlsym(handle, "libentry"));
const char *dlsym_error = dlerror();
if (dlsym_error) {
printf("Can not load symbol libentry: %s\n", dlsym_error);
dlclose(handle);
return 0;
}
printf("Calling libentry in %s...\n", libname);
lib_entry_();
return handle;
}
int main() {
var mainvar;
mainvar.inc("exe", 5);
mainvar.output("exe");
void* handle1 = load_lib_and_call("./libvar1.so");
void* handle2 = load_lib_and_call("./libvar2.so");
if (handle1)
dlclose(handle1);
if (handle2)
dlclose(handle2);
return 0;
}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/18276] New: AArch64: readelf, gas do not support TLSLD relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=18276
Bug ID: 18276
Summary: AArch64: readelf, gas do not support TLSLD relocations
Product: binutils
Version: 2.26 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: jingyuuiuc at gmail dot com
Clang aarch64 backend generates some TLSLD relocations that readelf and gas do
not support.
For example,
$cat tlsld.c
extern int __thread v_ld1a __attribute__ ((tls_model("local-dynamic")));
extern int __thread v_ld1b __attribute__ ((tls_model("local-dynamic")));
int f_ld1 () { return v_ld1a + v_ld1b; }
void s (int i) { v_ld1a = v_ld1b = i; }
int main(int argc, char** argv) {
s(argc);
return f_ld1();
}
$ clang tlsld.c -fPIC -mllvm -aarch64-elf-ldtls-generation -c -o tlsld.o
readelf does not recognize some relocations.
$ readelf -r tlsld.o
...
001c 000d0210 unrecognized: 210 v_ld1a + 0
0020 000d0212 unrecognized: 212 v_ld1a + 0
...
0044 000e0210 unrecognized: 210 v_ld1b + 0
0048 000e0212 unrecognized: 212 v_ld1b + 0
...
GAS does not support them either.
$ clang tlsld.c -fPIC -mllvm -aarch64-elf-ldtls-generation -S -o tlsld.s
$ gcc tlsld.s
tlsld.s: Assembler messages:
tlsld.s:16: Error: unknown relocation modifier at operand 3 -- `add
x0,x0,:dtprel_hi12:v_ld1a'
tlsld.s:17: Error: unknown relocation modifier at operand 3 -- `add
x0,x0,:dtprel_lo12_nc:v_ld1a'
tlsld.s:27: Error: unknown relocation modifier at operand 3 -- `add
x8,x0,:dtprel_hi12:v_ld1b'
tlsld.s:28: Error: unknown relocation modifier at operand 3 -- `add
x8,x8,:dtprel_lo12_nc:v_ld1b'
tlsld.s:56: Error: unknown relocation modifier at operand 3 -- `add
x0,x0,:dtprel_hi12:v_ld1b'
tlsld.s:57: Error: unknown relocation modifier at operand 3 -- `add
x0,x0,:dtprel_lo12_nc:v_ld1b'
tlsld.s:67: Error: unknown relocation modifier at operand 3 -- `add
x8,x0,:dtprel_hi12:v_ld1a'
tlsld.s:68: Error: unknown relocation modifier at operand 3 -- `add
x8,x8,:dtprel_lo12_nc:v_ld1a'
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
