1

I've been thinking about this for a while because I've observed that even really fundamental libraries like libc have a GOT/PLT, consisting of important functionality such as malloc() and its friends.

Is it even possible to create a shared library that has no GOT/PLT? Would such a library ever crop up in the wild, outside of an academic exercise? (If it helps, consider exclusively the x86 platform)

My gut tells me the answers to those questions are "no" and "yes" respectively, but I'm not 100% certain on either.

Is it possible that a .so file that just contains a list of C types won't have a GOT/PLT? Maybe, but I can't understand why that would occur in practice when you can just #include a .h file to do that!

too honest for this site
  • 12,050
  • 4
  • 30
  • 52
rmg
  • 59
  • 5
  • 1
    An .so file cannot contain a list of types because a type doesn't produce any object code. (Unless you have debugging information.) So a source file consisting only of type definitions would be the same as an empty source file. – rici Jul 18 '17 at 16:44
  • Completely unrelated to C. Don't spam tags. – too honest for this site Jul 18 '17 at 17:47
  • @rici: Did you mean `.so` files? In many languages, *source* files can have only type definitions, and they are not empty. – Rudy Velthuis Jul 18 '17 at 20:12
  • @rudy: if you consider a method's implementation to be part of the type definition, that is certainly true of some languages, but this question says "C types"and it was tagged [tag:c] when I saw it. In that context, I think my statement stands. – rici Jul 18 '17 at 20:30
  • @rici: I consider the definition of any type to be a type definition. Can be structs, arrays, enums, etc. In C, a header file is a source file too, and it can certainly contain only type definitions. Hence my question if you perhaps meant `.so` files instead, and not **source** files. – Rudy Velthuis Jul 18 '17 at 20:34
  • @rudy: ah. Yes, I meant source files. The only interpretation of "a .so file that just contains a list of C types" that made any sense to me was that the shared object resulted from the translation of a C file containing only type declarations. Such a source file would produce the same compiled object as an empty source file. – rici Jul 18 '17 at 21:31

1 Answers1

0

I wound up finding an answer to the second part of the question, and it seems to be "no". I have just under 5500 .so files in my /lib directory, and I ran the following shell script, called sotest.sh: 

#!/bin/bash
for i in $( ls /lib ); do
  objdump -d -j .plt /lib/$i &> /tmp/tmpfile.txt;
  a=`grep "File format not recognized" /tmp/tmpfile.txt`
  b=`grep "not an ordinary file" /tmp/tmpfile.txt`
  c=`grep "not found in any input file" /tmp/tmpfile.txt`
  if [ -n "$a" ]; then
    echo "Invalid";
  elif [ -n "$b" ]; then
    echo "Invalid";
  elif [ -n "$c" ]; then
    echo "$i HAS NO PLT SECTION";
  else
    echo "$i has plt section";
  fi
  rm /tmp/tmpfile.txt;
done
echo "Done"

I then ran ./sotest.sh | grep "HAS NO PLT SECTION". I did have some results, but all were .a files and none were .so files.

So, in practice, it doesn't seem like you will ever run across a .so file without a PLT/GOT in the wild. I'm still curious if it's possible in theory, but I found the answer to the practical side of my question, so I thought it could help others who were wondering the same thing!

rmg
  • 59
  • 5
  • Elf libraries normally contain initialiser and finalizer entries, even if they are no-ops. These functions will have GOT entries. I don't know if these functions are required or just conventional but I think you will find them in any shared object created by gcc. – rici Jul 18 '17 at 21:36