A student pointed out that in hw2, the constructor function in libckpt.a
was calling signal(), but that the definition of signal() was in libc.a,
which is not part of libckpt.a.  In fact, libcpt.a calls many functions
inside libc.a.  If those calls are position-dependent, then we will
have a problem injecting the code to an arbitrary location in memory.

This is related to our discussions concerning short-hw1, in which we
analyze how code is _really_ linked with the various libraries.
It's also related to hw2 (mini-DMTCP) in which we employed
  -Wl,-Ttext-segment=5000000 -Wl,-Tdata=5100000 -Wl,-Tbss=5200000

In principle, we only need to produce a fully linked code for
libckpt.a and libc.a at a non-conflicting address like
  0x5000000
Unfortunately, we don't know if libc.a has already been compiled to be
position-independent.

REMARK (on position-independent code):
    The decision on whether to produce position-independent code or
position-dependent code must be made at compiler time, since the
compiler must emit one form or another of assembly instructions.
When you disassemble, it is easy to recognize a position-independent
function call.  It will include position-independent addresses like:
      0x2c0433(%rip)  # Address given by "$pc + 0x2c0433"
    For security reasons, most Linux distros go to great lengths to
ensure that dynamic libraries, like libc.so, can be loaded at
any random address.  In Linux, this is part of
ASLR (Address Space Layout Randomization).  To see if this is turned on
in your Linux, do:
      cat /proc/sys/kernel/randomize_va_space
    Unfortunately for us, static executables are usually _not_ randomized
to be loaded at an arbitrary address.  So, we must still worry about
address conflicts.
    Some newer distributions, like Fedora 23, built their packages
not only with randomized addresses for _libraries_, but also with
randomized addresses for their text segment (e.g., using "gcc -fPIE").
    In fact, there are two options for placing a library at a randomized
address in memory.  One is to compile it with -fPIC, so that _internal_
calls within that library are position-independent.  The other is
to rely on the linker to link it into a new address in memory, and to
patch any existing addresses (e.g., target of "callq") so that they
refer to the absolute address where the function was actually loaded
in the end.
END OF REMARK

Next, let's apply the knowledge in the remark.

A quick look at:
  locate libc.a ==> /usr/lib/x86_64-linux-gnu/libc.a
  readelf -S /usr/lib/x86_64-linux-gnu/libc.a
 OR:
  disassemble /usr/lib/x86_64-linux-gnu/libc.a
shows that the program on disk has not yet had its function re-linked
to correspond to any particular address in memory.  Instead,
all assembly calls, "callq", are pointing to addresses close to zero.
Further, the targets of "callq" are not position-independent.

So, we can either re-link libc.a ourselves (yuck!), or else patch
our libckpt.a to point its addresses toward the libc.a of the
user executable (yuck!), or else invoke the linker on libc.a prior
to injecting our own copy of libc.a into memory.  We'll do the latter.

To summarise, there are at least two possible approaches here:
 a.  Compile libckpt.a and a corresponding libc.a to be position-independent
     code.  It does not appear that libc.a is using position-independent
     code.  So, even if we could patch the links between libckpt.a and
     libc.a, we might still have problems.
 b.  Or else, we can invoke the linker to patch the calls for us.
     Let's explore the second option.

The linker does not want to patch target addresses until it generates
the final executable.  This is very reasonable of the linker.
(After all, why would we patch addresses to link just libckpt.a and libc.a
 together, and then go back and patch all the addresses one more time
 when we generate the final a.out.)
If we were generating dynamically linked executables, then the
executable file would not include the separate dyanmcic libraries like
libc.so, and some of the linking would have to be done at runtime.
Luckily, in part 1, we are working with statically linked executables.
In this case, everything will be linked at the time of generating the
executable.

So, our solution is to generate a full executable.  We'll create an
arbitrary file, my_executable.c, with a main() routine, and we'll
ask the linker to create a fully linked executable.  We'll inject
all of that into memory, but we won't actually use the main() routine
of my_executable.c.  We'll only use libckpt.a and libc.a.

One possible solution is:
  gcc -static -fPIC -DPIC my_executable.c libckpt.a -o executable
Make sure that executable.c includes a call to your constructor function.
We don't want the linker to optimze, and omit libckpt.a on the linker's
assumption that we'll never call any functions in libckpt.a.
This will now create an executable file that includes your constructor function
and also includes the definition of signal() (in libc.a).

After a disassembly of your constructor function, you'll see that it's
actually calling something like _bsd_signal().  You'll want to make sure
that the call to _bsd_signal() is position-independent (e.g., using an
address format like 0x2c0433(%rip) ).  Unfortunately, you'll find
that this is not the case.

To verify how libckpt.a calls libc.a, check what was output.
One method for doing this is to compile everything with "-g 0O0".
Then:
  gdb my_executable
  (gdb) break read    # or any other system call in libc.a
  (gdb) run
  (gdb) where         # shows two call frames:  main() and read()
  (gdb) frame 1       # go to call frame of main()
  (gdb) x/10i $pc-20  # and look at the assembly code, after all the linking

In our next attempt, we could also add -fPIE.  But this will help
only if libc.a is already compiled in position-independent format.
Unfortunately, this is not the case.

So, now we go back and use our insights from hw2 (mini-DMTCP).  We give
up on fully position-independent code.  (Maybe a future Linux distro
will make this easier to do.)  Instead, we choose a non-conflicting
address in advance, and compile our code to be targeted toward
that address:

  gcc -Wl,-Ttext-segment=5000000 -Wl,-Tdata=5100000 -Wl,-Tbss=5200000 \
      my_executable.c libckpt.a -o my_executable

Optionally, add flags like "-fPID -DPIC -g -O0", as desired.
Use "objdump -d my_executable" or "disassemble my_executable"
to discover the address of the constructor in libckpt.a.
(And if this hadn't work, you would look for the address where the text
 segment will be loaded, using "readelf -S", and then find the offset
 from the beginning of text for the constructor.)
Perhaps, as a sanity test, also do:
  readelf -S my_executable

Now, you can inject 'my_executable' into your running process.