why boost::scoped_ptr is cleared in a singleton implementation - c++

I implemented a simple singleton by using boost::scoped_ptr:
template <class T> class Singleton : public boost::noncopyable {
public:
static T& instance() {
boost::call_once(init, flag);
return *t;
}
static void init() {
t.reset(new T());
}
private:
static boost::scoped_ptr <T> t;
static boost::once_flag flag;
};
template <class T> boost::scoped_ptr<T> Singleton<T>::t(0);
template <class T> boost::once_flag Singleton<T>::flag = BOOST_ONCE_INIT;
Define a real singleton class:
class S : public Singleton<S> {
public:
void p() { printf("hello");}
};
Then I define a static variable in file S.cpp:
static volatile S &S_instance = S::instance();
in main.cpp:
int main()
{
S &ss = S::instance();
ss.p();
}
Run this program, an exception happened:
/usr/include/boost/smart_ptr/scoped_ptr.hpp:91: T& boost::scoped_ptr::operator*() const [with T = S]: Assertion `px != 0' failed
Tracing the code, I found the static s_instance.t is cleared once the code leaves the static initialization segment and after that all code referring to the S::instance will get NULL scoped_ptr. Does anybody know the reason?
[UPDATE]
I tried to put all static into one cpp file (S1.cpp):
template <class T> boost::scoped_ptr<T> Singleton<T>::t(0);
template <class T> boost::once_flag Singleton<T>::flag = BOOST_ONCE_INIT;
static S& s_ins = S::instance();
and debug it with GDB, it looks follow the order I wrote. any idea?

A possible reason is that the static template <class T> boost::scoped_ptr<T> Singleton<T>::t(0); is initialized after the static volatile S &S_instance = S::instance();, and thus it replaced with 0 the value previously stored in t. The order in which the static variables are constructed is only defined within a single compilation unit, and I guess in your case t can be instantiated inside main.cpp (or rather in both files at compilation time, and the linker will have to choose just one) while S resides in S.cpp. Just a guess though.

I'm pretty sure that it is undefined behavior due to undefined creation order of global variables. So, your S_instance first initialized, and then template <class T> boost::scoped_ptr<T> Singleton<T>::t(0)
Such a simple program can illustrate, what can happen when order is reversed:
#include <iostream>
std::string &getS();
std::string& t = getS();
std::string s("hello");
std::string &getS() {s = "world"; return s;}
int main()
{
std::cout << t;
}
Well, it crashes for me with g++ and prints hello with cl

Your program works correctly (when compiled as a single file) if you remove this line:
static volatile S &S_instance = S::instance();
OK. When built on my machine without your S_instance declaration:
0000000000400d86 <__static_initialization_and_destruction_0(int, int)>:
400d86: 55 push %rbp
400d87: 48 89 e5 mov %rsp,%rbp
400d8a: 48 83 ec 10 sub $0x10,%rsp
400d8e: 89 7d fc mov %edi,-0x4(%rbp)
400d91: 89 75 f8 mov %esi,-0x8(%rbp)
400d94: 83 7d fc 01 cmpl $0x1,-0x4(%rbp)
400d98: 75 43 jne 400ddd <__static_initialization_and_destruction_0(int, int)+0x57>
400d9a: 81 7d f8 ff ff 00 00 cmpl $0xffff,-0x8(%rbp)
400da1: 75 3a jne 400ddd <__static_initialization_and_destruction_0(int, int)+0x57>
400da3: b8 b8 40 40 00 mov $0x4040b8,%eax
400da8: 0f b6 00 movzbl (%rax),%eax
400dab: 84 c0 test %al,%al
400dad: 75 2e jne 400ddd <__static_initialization_and_destruction_0(int, int)+0x57>
400daf: b8 b8 40 40 00 mov $0x4040b8,%eax
400db4: c6 00 01 movb $0x1,(%rax)
400db7: be 00 00 00 00 mov $0x0,%esi
400dbc: bf b0 40 40 00 mov $0x4040b0,%edi
400dc1: e8 3c 05 00 00 callq 401302 <boost::scoped_ptr<S>::scoped_ptr(S*)>
400dc6: b8 da 13 40 00 mov $0x4013da,%eax
400dcb: ba 90 40 40 00 mov $0x404090,%edx
400dd0: be b0 40 40 00 mov $0x4040b0,%esi
400dd5: 48 89 c7 mov %rax,%rdi
400dd8: e8 8b fd ff ff callq 400b68 <__cxa_atexit#plt>
400ddd: c9 leaveq
400dde: c3 retq
When compiled with your S_instance declaration:
0000000000400d86 <__static_initialization_and_destruction_0(int, int)>:
400d86: 55 push %rbp
400d87: 48 89 e5 mov %rsp,%rbp
400d8a: 48 83 ec 10 sub $0x10,%rsp
400d8e: 89 7d fc mov %edi,-0x4(%rbp)
400d91: 89 75 f8 mov %esi,-0x8(%rbp)
400d94: 83 7d fc 01 cmpl $0x1,-0x4(%rbp)
400d98: 75 4f jne 400de9 <__static_initialization_and_destruction_0(int, int)+0x63>
400d9a: 81 7d f8 ff ff 00 00 cmpl $0xffff,-0x8(%rbp)
400da1: 75 46 jne 400de9 <__static_initialization_and_destruction_0(int, int)+0x63>
400da3: e8 c2 04 00 00 callq 40126a <Singleton<S>::instance()>
400da8: 48 89 05 01 33 00 00 mov %rax,0x3301(%rip) # 4040b0 <S_instance>
400daf: b8 c0 40 40 00 mov $0x4040c0,%eax
400db4: 0f b6 00 movzbl (%rax),%eax
400db7: 84 c0 test %al,%al
400db9: 75 2e jne 400de9 <__static_initialization_and_destruction_0(int, int)+0x63>
400dbb: b8 c0 40 40 00 mov $0x4040c0,%eax
400dc0: c6 00 01 movb $0x1,(%rax)
400dc3: be 00 00 00 00 mov $0x0,%esi
400dc8: bf b8 40 40 00 mov $0x4040b8,%edi
400dcd: e8 3c 05 00 00 callq 40130e <boost::scoped_ptr<S>::scoped_ptr(S*)>
400dd2: b8 e6 13 40 00 mov $0x4013e6,%eax
400dd7: ba 90 40 40 00 mov $0x404090,%edx
400ddc: be b8 40 40 00 mov $0x4040b8,%esi
400de1: 48 89 c7 mov %rax,%rdi
400de4: e8 7f fd ff ff callq 400b68 <__cxa_atexit#plt>
400de9: c9 leaveq
400dea: c3 retq
In the latter code, you can clearly see that the constructor for the static scoped_ptr happens after S_instance.
The above were compiled from:
#include <cstdio>
#include <boost/scoped_ptr.hpp>
#include <boost/thread/once.hpp>
#include <boost/noncopyable.hpp>
template <class T> class Singleton : public boost::noncopyable {
public:
static T& instance() {
boost::call_once(init, flag);
return *t;
}
static void init() {
t.reset(new T());
}
private:
static boost::scoped_ptr <T> t;
static boost::once_flag flag;
};
template <class T> boost::scoped_ptr<T> Singleton<T>::t(0);
template <class T> boost::once_flag Singleton<T>::flag = BOOST_ONCE_INIT;
class S : public Singleton<S> {
public:
void p() { printf("hello");}
};
// static volatile S &S_instance = S::instance();
int main()
{
S &ss = S::instance();
ss.p();
}

I think that this is wrong:
static volatile S &S_instance = S::instance();
because it creates and then deletes the instance. You want a pointer, not a reference.
static S *S_instance = &S::instance();
As far as I know the reference goes out of scope at the end of the .cpp file. The instance is not expected to ever be deleted anyway, so T can just be a bare pointer.

Related

finstrument-functions-exclude-function-list appears to not handle commas properly

Attempting to compile with finstrument-functions and exclude a template function with multiple template parameters, using the \ method to escape commas (as described for exclude-file-list here) fails to properly disable instrumenting the function passed.
GCC command used:
gcc -finstrument-functions -finstrument-functions-exclude-function-list='test<float\, int>' main.cpp -o a.out -O0
Above creates a binary file with the "test" function instrumented. Assembly snippet and main.cpp file included below
gcc -dumpversion returns "6.2.0", above command run on red hat enterprise linux, version 7.4
Contents of main.cpp:
template<class T, class U>
T test(int a, T b){
int res = 0;
for(int i = 0; i < 1000; i++){
res += i;
}
return(res);
}
int main(int argc, char** argv){
float a = test<float, int>(argc, 1.0);
return(0);
}
objdumped output for "test" function:
000000000040059f <float test<float, int>(int, float)>:
40059f: 55 push %rbp
4005a0: 48 89 e5 mov %rsp,%rbp
4005a3: 48 83 ec 20 sub $0x20,%rsp
4005a7: 89 7d ec mov %edi,-0x14(%rbp)
4005aa: f3 0f 11 45 e8 movss %xmm0,-0x18(%rbp)
4005af: 48 8b 45 08 mov 0x8(%rbp),%rax
4005b3: 48 89 c6 mov %rax,%rsi
4005b6: bf 9f 05 40 00 mov $0x40059f,%edi
4005bb: e8 70 fe ff ff callq 400430 <__cyg_profile_func_enter#plt>
4005c0: c7 45 f8 00 00 00 00 movl $0x0,-0x8(%rbp)
4005c7: c7 45 fc 00 00 00 00 movl $0x0,-0x4(%rbp)
4005ce: 81 7d fc e7 03 00 00 cmpl $0x3e7,-0x4(%rbp)
4005d5: 7f 11 jg 4005e8 <float test<float, int>(int, float)+0x49>
4005d7: 8b 55 f8 mov -0x8(%rbp),%edx
4005da: 8b 45 fc mov -0x4(%rbp),%eax
4005dd: 01 d0 add %edx,%eax
4005df: 89 45 f8 mov %eax,-0x8(%rbp)
4005e2: 83 45 fc 01 addl $0x1,-0x4(%rbp)
4005e6: eb e6 jmp 4005ce <float test<float, int>(int, float)+0x2f>
4005e8: 8b 45 f8 mov -0x8(%rbp),%eax
4005eb: 66 0f ef c9 pxor %xmm1,%xmm1
4005ef: f3 0f 2a c8 cvtsi2ss %eax,%xmm1
4005f3: f3 0f 11 4d e4 movss %xmm1,-0x1c(%rbp)
4005f8: 48 8b 45 08 mov 0x8(%rbp),%rax
4005fc: 48 89 c6 mov %rax,%rsi
4005ff: bf 9f 05 40 00 mov $0x40059f,%edi
400604: e8 17 fe ff ff callq 400420 <__cyg_profile_func_exit#plt>
400609: f3 0f 10 45 e4 movss -0x1c(%rbp),%xmm0
40060e: c9 leaveq
40060f: c3 retq
I expected the test function to not be instrumented, but it is. Does anyone know why this is?
Compiler explorer example
Just in case anyone comes by this way, both this and finstrument-functions-exclude-function-list not respecting namespace parts of a function are bugs, and I have filed against both. Hopefully a fix will be implemented soon (working on one currently).
Namespace / class mishandling
Comma mishandling

C++ assembly code analysis (compiled with clang)

I am trying to figure out how the C++ binary code looks like, especially for virtual function calls. I have come up with few curious things. I have this following C++ code:
#include <iostream>
using namespace std;
class Base {
public:
virtual void print() { cout << "from base" << endl; }
};
class Derived : public Base {
public:
virtual void print() { cout << "from derived" << endl; }
};
int main() {
Base *b;
Derived d;
d.print();
b = &d;
b->print();
return 0;
}
I compiled it with clang++, and then use objdump:
00000000004008b0 <main>:
4008b0: 55 push rbp
4008b1: 48 89 e5 mov rbp,rsp
4008b4: 48 83 ec 20 sub rsp,0x20
4008b8: 48 8d 7d e8 lea rdi,[rbp-0x18]
4008bc: c7 45 fc 00 00 00 00 mov DWORD PTR [rbp-0x4],0x0
4008c3: e8 28 00 00 00 call 4008f0 <Derived::Derived()>
4008c8: 48 8d 7d e8 lea rdi,[rbp-0x18]
4008cc: e8 5f 00 00 00 call 400930 <Derived::print()>
4008d1: 48 8d 7d e8 lea rdi,[rbp-0x18]
4008d5: 48 89 7d f0 mov QWORD PTR [rbp-0x10],rdi
4008d9: 48 8b 7d f0 mov rdi,QWORD PTR [rbp-0x10]
4008dd: 48 8b 07 mov rax,QWORD PTR [rdi]
4008e0: ff 10 call QWORD PTR [rax]
4008e2: 31 c0 xor eax,eax
4008e4: 48 83 c4 20 add rsp,0x20
4008e8: 5d pop rbp
4008e9: c3 ret
4008ea: 66 0f 1f 44 00 00 nop WORD PTR [rax+rax*1+0x0]
My question is why in assembly code, we have the following code:
4008b8: 48 8d 7d e8 lea rdi,[rbp-0x18]
4008d1: 48 8d 7d e8 lea rdi,[rbp-0x18]
The local variable d in main() is stored at location [rbp-0x18]. This is in the automatic storage allocated on the stack for main().
lea rdi,[rbp-0x18]
This line loads the address of d into the rdi register. By convention, member functions of Derived treat rdi as the this pointer.

Member initializer list, pointer initialization without argument

In a large framework which used to use many smart pointers and now uses raw pointers, I come across situations like this quite often:
class A {
public:
int* m;
A() : m() {}
};
The reason is because int* m used to be a smart pointer and so the initializer list called a default constructor. Now that int* m is a raw pointer I am not certain if this is equivalent to:
class A {
public:
int* m;
A() : m(nullptr) {}
};
Without the explicit nullptr is A::m still initialized to zero? A look at no optimization objdump -d makes it appear to be yes but I am not certain. The reason I feel that the answer is yes is due to this line in the objdump -d (I posted more of the objdump -d below):
400644: 48 c7 00 00 00 00 00 movq $0x0,(%rax)
Little program that tries to find undefined behavior:
class A {
public:
int* m;
A() : m(nullptr) {}
};
int main() {
A buf[1000000];
unsigned int count = 0;
for (unsigned int i = 0; i < 1000000; ++i) {
count += buf[i].m ? 1 : 0;
}
return count;
}
Compilation, execution, and return value:
g++ -std=c++14 -O0 foo.cpp
./a.out; echo $?
0
Relevant assembly sections from objdump -d:
00000000004005b8 <main>:
4005b8: 55 push %rbp
4005b9: 48 89 e5 mov %rsp,%rbp
4005bc: 41 54 push %r12
4005be: 53 push %rbx
4005bf: 48 81 ec 10 12 7a 00 sub $0x7a1210,%rsp
4005c6: 48 8d 85 e0 ed 85 ff lea -0x7a1220(%rbp),%rax
4005cd: bb 3f 42 0f 00 mov $0xf423f,%ebx
4005d2: 49 89 c4 mov %rax,%r12
4005d5: eb 10 jmp 4005e7 <main+0x2f>
4005d7: 4c 89 e7 mov %r12,%rdi
4005da: e8 59 00 00 00 callq 400638 <_ZN1AC1Ev>
4005df: 49 83 c4 08 add $0x8,%r12
4005e3: 48 83 eb 01 sub $0x1,%rbx
4005e7: 48 83 fb ff cmp $0xffffffffffffffff,%rbx
4005eb: 75 ea jne 4005d7 <main+0x1f>
4005ed: c7 45 ec 00 00 00 00 movl $0x0,-0x14(%rbp)
4005f4: c7 45 e8 00 00 00 00 movl $0x0,-0x18(%rbp)
4005fb: eb 23 jmp 400620 <main+0x68>
4005fd: 8b 45 e8 mov -0x18(%rbp),%eax
400600: 48 8b 84 c5 e0 ed 85 mov -0x7a1220(%rbp,%rax,8),%rax
400607: ff
400608: 48 85 c0 test %rax,%rax
40060b: 74 07 je 400614 <main+0x5c>
40060d: b8 01 00 00 00 mov $0x1,%eax
400612: eb 05 jmp 400619 <main+0x61>
400614: b8 00 00 00 00 mov $0x0,%eax
400619: 01 45 ec add %eax,-0x14(%rbp)
40061c: 83 45 e8 01 addl $0x1,-0x18(%rbp)
400620: 81 7d e8 3f 42 0f 00 cmpl $0xf423f,-0x18(%rbp)
400627: 76 d4 jbe 4005fd <main+0x45>
400629: 8b 45 ec mov -0x14(%rbp),%eax
40062c: 48 81 c4 10 12 7a 00 add $0x7a1210,%rsp
400633: 5b pop %rbx
400634: 41 5c pop %r12
400636: 5d pop %rbp
400637: c3 retq
0000000000400638 <_ZN1AC1Ev>:
400638: 55 push %rbp
400639: 48 89 e5 mov %rsp,%rbp
40063c: 48 89 7d f8 mov %rdi,-0x8(%rbp)
400640: 48 8b 45 f8 mov -0x8(%rbp),%rax
400644: 48 c7 00 00 00 00 00 movq $0x0,(%rax)
40064b: 5d pop %rbp
40064c: c3 retq
40064d: 0f 1f 00 nopl (%rax)
Empty () initializer stands for default-initialization in C++98 and for value-initialization in C++03 and later. For scalar types (including pointers) value-initialization/default-initialization leads to zero-initialization.
Which means that in your case m() and m(nullptr) will have exactly the same effect: in both cases m is initialized as a null pointer. In C++ it was like that since the beginning of standardized times.

Why new&delete operator symbols in shared-obj is to be relocated even if they are implemented in that shared-obj?

I am try to implement my own c++ new & delete operators in my program as bellow:
#include <stdio.h>
#include <stdlib.h>
#include <new>
using namespace std;
void *operator new(std::size_t size) throw(std::bad_alloc)
{
printf("My new is called!\n");
return malloc(size);
}
void operator delete(void *ptr) throw ()
{
printf("My delete is called!\n");
free(ptr);
}
void *operator new(std::size_t size, const std::nothrow_t&) throw()
{
return malloc(size);
}
void operator delete(void *ptr, const std::nothrow_t&) throw()
{
free(ptr);
}
void *operator new[](std::size_t size) throw(std::bad_alloc)
{
return malloc(size);
}
void operator delete[](void *ptr) throw ()
{
free(ptr);
}
void *operator new[](std::size_t size,
const std::nothrow_t&) throw()
{
return malloc(size);
}
void operator delete[](void *ptr,
const std::nothrow_t&) throw()
{
free(ptr);
}
class Object
{
public:
Object() {}
~Object() {}
private:
int a;
};
int main()
{
Object* obj = new Object();
if (obj)
delete obj;
return 0;
}
Then I find that, if the program is built out as:
-- an exe, then my new/delete is called as expected
-- but,, a shared-object, then symbols of new & delete is to be relocated, so in my env when this so is loaded by dlopen in another program then the new & delete will be mapped to another program's new & delete...
The detailed information is as bellow...
build out an exe:
gcc -m32 -c main.cpp
gcc -m32 main.o -o main.exe
$ ./main.exe
My new is called!
My delete is called!
$ objdump -d main.exe
080484ac :
80484ac: 55 push %ebp
80484ad: 89 e5 mov %esp,%ebp
80484af: 53 push %ebx
80484b0: 83 ec 24 sub $0x24,%esp
80484b3: 83 e4 f0 and $0xfffffff0,%esp
80484b6: b8 00 00 00 00 mov $0x0,%eax
80484bb: 83 c0 0f add $0xf,%eax
80484be: 83 c0 0f add $0xf,%eax
80484c1: c1 e8 04 shr $0x4,%eax
80484c4: c1 e0 04 shl $0x4,%eax
80484c7: 29 c4 sub %eax,%esp
80484c9: c7 04 24 04 00 00 00 movl $0x4,(%esp)
80484d0: e8 1f ff ff ff call 80483f4 <_Znwj> --> new: expected!!
80484d5: 89 c3 mov %eax,%ebx
80484d7: 89 1c 24 mov %ebx,(%esp)
80484da: e8 35 00 00 00 call 8048514 <_ZN6ObjectC1Ev>
80484df: 89 5d f8 mov %ebx,-0x8(%ebp)
80484e2: 83 7d f8 00 cmpl $0x0,-0x8(%ebp)
80484e6: 74 22 je 804850a
80484e8: 8b 45 f8 mov -0x8(%ebp),%eax
80484eb: 89 45 e8 mov %eax,-0x18(%ebp)
80484ee: 83 7d e8 00 cmpl $0x0,-0x18(%ebp)
80484f2: 74 16 je 804850a
80484f4: 8b 45 e8 mov -0x18(%ebp),%eax
80484f7: 89 04 24 mov %eax,(%esp)
80484fa: e8 1b 00 00 00 call 804851a <_ZN6ObjectD1Ev>
80484ff: 8b 45 e8 mov -0x18(%ebp),%eax
8048502: 89 04 24 mov %eax,(%esp)
8048505: e8 0a ff ff ff call 8048414 <_ZdlPv> --> delete: expected
build out a shared object:
gcc -m32 -c main.cpp
gcc --shared -m32 main.o -o main.so
$ objdump -d main.so
000006d4 :
6d4: 55 push %ebp
6d5: 89 e5 mov %esp,%ebp
6d7: 53 push %ebx
6d8: 83 ec 24 sub $0x24,%esp
6db: 83 e4 f0 and $0xfffffff0,%esp
6de: b8 00 00 00 00 mov $0x0,%eax
6e3: 83 c0 0f add $0xf,%eax
6e6: 83 c0 0f add $0xf,%eax
6e9: c1 e8 04 shr $0x4,%eax
6ec: c1 e0 04 shl $0x4,%eax
6ef: 29 c4 sub %eax,%esp
6f1: c7 04 24 04 00 00 00 movl $0x4,(%esp)
6f8: e8 fc ff ff ff call 6f9 ---> new: to be relocated, unexpected :(
6fd: 89 c3 mov %eax,%ebx
6ff: 89 1c 24 mov %ebx,(%esp)
702: e8 fc ff ff ff call 703
707: 89 5d f8 mov %ebx,-0x8(%ebp)
70a: 83 7d f8 00 cmpl $0x0,-0x8(%ebp)
70e: 74 22 je 732
710: 8b 45 f8 mov -0x8(%ebp),%eax
713: 89 45 e8 mov %eax,-0x18(%ebp)
716: 83 7d e8 00 cmpl $0x0,-0x18(%ebp)
71a: 74 16 je 732
71c: 8b 45 e8 mov -0x18(%ebp),%eax
71f: 89 04 24 mov %eax,(%esp)
722: e8 fc ff ff ff call 723 ---> delete: to be relocated, unexpected :(
727: 8b 45 e8 mov -0x18(%ebp),%eax
72a: 89 04 24 mov %eax,(%esp)
72d: e8 fc ff ff ff call 72e
but, a shared-object, then symbols of new & delete is to be relocated
This is exactly as designed (UNIX shared libraries work very differently from Windows shared libraries in that respect).
The reason: symbol interpositioning. For example, on UNIX you can link in an alternative malloc implementation (e.g. tcmalloc) into the main executable, and every shared library, including libc.so which provides its own malloc, will call your malloc.
If you want to achieve Windows-like symbol binding on UNIX, the -Bsymbolic linker flag might do what you want (read man ld on your platform).
If you are on Linux or Solaris, gcc -shared -Wl,-Bsymbolic ... should do what you want. Beware: there are many gotcha's in going "against the system". You may come to regret trying to do it this way.

"call" instruction that seemingly jumps into itself

I have some C++ code
#include <cstdio>
#include <boost/bind.hpp>
#include <boost/function.hpp>
class A {
public:
void do_it() { std::printf("aaa"); }
};
void
call_it(const boost::function<void()> &f)
{
f();
}
void
func()
{
A *a = new A;
call_it(boost::bind(&A::do_it, a));
}
which gcc 4 compiles into the following assembly (from objdump):
00000030 <func()>:
30: 55 push %ebp
31: 89 e5 mov %esp,%ebp
33: 56 push %esi
34: 31 f6 xor %esi,%esi
36: 53 push %ebx
37: bb 00 00 00 00 mov $0x0,%ebx
3c: 83 ec 40 sub $0x40,%esp
3f: c7 04 24 01 00 00 00 movl $0x1,(%esp)
46: e8 fc ff ff ff call 47 <func()+0x17>
4b: 8d 55 ec lea 0xffffffec(%ebp),%edx
4e: 89 14 24 mov %edx,(%esp)
51: 89 5c 24 04 mov %ebx,0x4(%esp)
55: 89 74 24 08 mov %esi,0x8(%esp)
59: 89 44 24 0c mov %eax,0xc(%esp)
; the rest of the function is omitted
I can't understand the operand of call instruction here, why does it call into itself, but with one byte off?
The call is probably to an external function, and the address you see (FFFFFFFC) is just a placeholder for the real address, which the linker and/or loader will take care of later.