Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance: Do not compile programs with PIC #3691

Closed
michaelrsweet opened this issue Oct 15, 2010 · 10 comments
Closed

Performance: Do not compile programs with PIC #3691

michaelrsweet opened this issue Oct 15, 2010 · 10 comments
Labels
priority-low wontfix
Milestone

Comments

@michaelrsweet
Copy link
Collaborator

michaelrsweet commented Oct 15, 2010

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
Copy link
Collaborator Author

michaelrsweet commented Jan 7, 2011

CUPS.org User: mike

Tim,

Does the attached patch fix builds for you?

@michaelrsweet
Copy link
Collaborator Author

michaelrsweet commented Jan 11, 2011

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
Copy link
Collaborator Author

michaelrsweet commented Jan 11, 2011

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
Copy link
Collaborator Author

michaelrsweet commented Jan 11, 2011

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
Copy link
Collaborator Author

michaelrsweet commented Jan 11, 2011

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
Copy link
Collaborator Author

michaelrsweet commented Jan 12, 2011

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
Copy link
Collaborator Author

michaelrsweet commented Jan 12, 2011

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
Copy link
Collaborator Author

michaelrsweet commented Jan 18, 2011

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
Copy link
Collaborator Author

michaelrsweet commented Jan 19, 2011

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
Copy link
Collaborator Author

michaelrsweet commented Feb 14, 2011

"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"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority-low wontfix
Projects
None yet
Development

No branches or pull requests

1 participant