Performance: Do not compile programs with PIC

[michaelrsweet]

Version: 1.4.4
CUPS.org User: twaugh.redhat

When GCC is available we try to use its support for creating position-independent executables (STR #1209). However, it is not currently working.

Object files destined for PIEs should be compiled with -fPIE (and not -fPIC).
They should be linked with -pie.

[michaelrsweet]

CUPS.org User: mike

Tim,

Does the attached patch fix builds for you?

[michaelrsweet]

CUPS.org User: twaugh.redhat

No.

You can't just build everything with "-fPIE -pie". You have to compile the objects for a PIE with -fPIE, and you have to link them with -pie.

If you are making a shared library, you must not compile with -fPIE but with -fPIC. It's one or the other: -fPIC compiles for a shared library, -fPIE compiles for a position-independent executable.

Currently when I try to build on Fedora 14 x86_64 the build fails with:

Linking libcups.so.2...
/usr/bin/ld: adminutil.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
adminutil.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[1]: *** [libcups.so.2] Error 1

Taking out ".SILENT:" from Makedefs I see that it didn't use either -fPIC or -fPIE there:

Compiling adminutil.c...
gcc -Wall -Wno-format-y2k -Os -g -fstack-protector -D_GNU_SOURCE -I.. -D_CUPS_SOURCE -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -DDBUS_API_SUBJECT_TO_CHANGE -DOPENSSL_DISABLE_OLD_DES_SUPPORT -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -c -o adminutil.o adminutil.c

...and in fact, the same is true of all objects compiled up to that point.

[michaelrsweet]

CUPS.org User: mike

I am somewhat inclined to remove Linux PIE support from 1.4.x and add it to 1.5.x, since doing what you propose (-fPIE only for program objects) is basically impossible with the current build system.

Are you sure we can't compile sources with both -fPIE and -fPIC and then just link with -pie for the applications?

[michaelrsweet]

CUPS.org User: twaugh.redhat

Are you sure we can't compile sources with both
-fPIE and -fPIC and then just link with -pie for
the applications?

Fairly sure. Doing so fails for me when linking shared libraries:

/usr/bin/ld: adminutil.o: relocation R_X86_64_PC32 against symbol `cupsAdminGetServerSettings' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make[1]: *** [libcups.so.2] Error 1

(adminutil.o was compiled with -fPIE here)

[michaelrsweet]

CUPS.org User: mike

OK, I have a VM with Fedora 14 setup now and am playing a bit. Unfortunately, with the original config script stuff PIE support is working great on Mac OS X, and as I mentioned we can't (easily) support different compiler options in a single makefile (and NO I will not use automake for this...)

Moreover, when I use the original config script I am seeing that cupsd (and all other programs) have the expected ELF type of "DYN" instead of "EXEC".

What exactly do you think is not working? How are you determining that it is not working?

[michaelrsweet]

CUPS.org User: twaugh.redhat

Well, it won't link. :-)

I expect you're trying on a 32-bit VM. Try a 64-bit one and you'll see the problem too. See comment #3 above for the exact error message. When I build the relevant objects by hand with the correct options it all links correctly and builds PIEs and shared libraries.

[michaelrsweet]

CUPS.org User: mike

No, I actually am using a 64-bit VM, and with my proposed patch got the same error you were seeing.

Without the patch (e.g. the standard 1.4.x release or current SVN trunk/branch-1.4) I do not get the error and readelf is reporting the right/expected stuff on scheduler/cupsd and cups/libcups.so.2.

Can you try current SVN trunk on your system?

[michaelrsweet]

CUPS.org User: twaugh.redhat

It looks like my original "not currently working" assessment was a bit strong. :-)

Yes, the binaries are type DYN, have no text relocations, and have a DEBUG section, so they are indeed position independent executables.

However, there is a slight performance penalty for compiling executable objects with -fPIC instead of -fpie because the compiler is not allowed to assume that locally defined non-static symbols won't be overridden, whereas in a PIE it can assume that.

So it looks like it is currently working, but:

1. is compiling with -fPIC in lots of places where -fpie (or -fPIE) would be preferable
2. is passing -fPIE on the command line when linking, which is completely ignored (it is a compile-time option not a link-time option)

[michaelrsweet]

CUPS.org User: mike

OK, I did some testing on Mac OS X and Fedora 14, both 64-bit intel, and found that compiling CUPS with shared libraries (which uses -fPIC for everything) vs compiling without shared libraries (no -fPIC, just -fPIE) made absolutely no difference in performance.

The benchmarks I did used "make test" with mode 0 (just start up a test cupsd), 10 PostScript printer queues pointed at /dev/null, and several runs of the scheduler/testspeed program using "-c 10 -r 100 localhost:8631".

So, unless you can show a significant improvement in performance I am going to close this bug out as "will not fix" since the necessary changes to separate programs from libraries in the CUPS source tree are not worth the trouble otherwise.

(changed the summary to reflect the actual issue)

[michaelrsweet]

"str3691.patch":

Index: config-scripts/cups-compiler.m4

--- config-scripts/cups-compiler.m4 (revision 9428)
+++ config-scripts/cups-compiler.m4 (working copy)
@@ -114,11 +114,6 @@
fi
fi

• Generate position-independent code as needed...

• if test $PICFLAG = 1 -a $uname != AIX; then

•       OPTIM="-fPIC $OPTIM"
  

- fi

# The -fstack-protector option is available with some versions of
# GCC and adds "stack canaries" which detect when the return address
# has been overwritten, preventing many types of exploit attacks.

@@ -143,6 +138,11 @@
AC_MSG_RESULT(no))
CFLAGS="$OLDCFLAGS"

• Generate position-independent code as needed...

• if test $PICFLAG = 1 -a $uname != AIX -a "x$PIEFLAGS" = x; then

•       OPTIM="-fPIC $OPTIM"
  

• fi

if test "x$with_optim" = x; then
# Add useful warning options for tracking down problems...
OPTIM="-Wall -Wno-format-y2k $OPTIM"