Re: -DPIC - redundant?

[Kevin F. Quinn]

Ralf Wildenhues (address@hidden) wrote:

> (It'd be great if you could enable your mailer to wrap long text lines.)
>
> * Kevin F. Quinn wrote on Thu, Jan 27, 2005 at 09:18:57AM CET:
> > Thanks people; I understand (now) that libtool supports many targets,
> > each with their own compilers.  I guess that means the question
> > becomes, why set -DPIC on targets that use gcc, where that compiler
> > defines __PIC__ if it's generating PIC code (at least since gcc 2.8.1
> > to my knowledge - I don't know about earlier versions)?
>
> Well, -DPIC means just that: you are compiling for position-independent
> objects.

To be specific here, it means libtool has set the options for PIC.  If the 
options for PIC are set by other means (i.e. not when using libtool, but 
perhaps by changing the compiler configuration), -DPIC may not be. I know this 
sounds pedantic, but I'll elaborate an example below to clarify where I'm 
coming from.  BTW I'm not suggesting libtool change its behaviour (if nothing 
else no doubt lots of stuff would break as a result, regardless whether it's 
redundant on a platform or not), but I do want to make sure I understand 
properly why libtool sets -DPIC, and so when and why one should write '#ifdef 
PIC' rather than '#ifdef __PIC__'

> > Presumably stuff that needs to use conditional compilation for
> > PIC/non-PIC code is compiler- and target-specific, so should use
>
> This is an assumption.  Might be valid often, but is an assumption.

I figure it may valid, since PIC specifics depend on the ABI, which depends on 
platform and toolchain.  I'd be genuinely interested in an example where it's 
not valid, though.

> > whatever support is provided in each case (where libtool could add a
> > define if otherwise there's nothing available from which to decide on
> > a given platform).  In the case of gcc targets, I think '#ifdef
> > __PIC__' should always be used, however there's a lot of code out
> > there doing '#ifdef PIC' inside GCC-specific assembler blocks (for
> > example).
>
> How are you going to use gcc-specific assembler in portable software?

By surrounding it with '#ifdef __GNUC__' etc and providing alternative source 
code for other platforms.  A common occurrence in multimedia software where 
performance is paramount for many users, is provision of hand-written assembler 
for the x86 platform (often several variants, using various combinations of 
SSE, MMX etc) with alternative normal non-assembler code for others (PPC, MIPS 
etc).  The code is then switched automatically with suitable preprocessor 
directives.  That way you can support any platform, while at the same time you 
don't have to sacrifice performance on platforms that need specific 
instructions to get it.

> Why specifically do you mind `#ifdef PIC' in the gcc-specific assembler?
> I mean, it's not going to be compiled by any other compiler anyway
> (and if so, one could arguably expect the other compiler to need the
> very same PIC-special code anyway).
>
> > I'd like to be able to say to people who use '#ifdef PIC'
> > for gcc-specific code (e.g. stuff inside an '#ifdef __GNUC__' block)
> > that they should be using __PIC__, and get it fixed accordingly.
>
> Why?  I mean, you can say that, but what does it buy you?
> These questions are honest.  Maybe it's best to provide a specific
> example why you think existing practice is not best.

Here's the example where '#ifdef PIC' causes problems.  In the Gentoo Hardened 
project, in order to build a system whereby as far as possible all software is 
PIC/PIE to take advantage of address space randomisation, the default gcc 
compiler configuration is altered to generate PIC on the x86 platform.  Where 
software is written conditionally on '__PIC__', it can work ok, unchanged (it 
might be slow, but that's a secondary consideration in this case).  Where code 
is conditional on 'PIC', it breaks (if the build isn't using libtool).  The 
decision I'm trying to make is whether to suggest to people they should write 
'#if defined(PIC) || defined(__PIC__)" instead of '#ifdef PIC', or whether to 
suggest '#ifdef __PIC__'.  It seems that unless the build uses libtool (in 
which case it probably works anyway), I can safely suggest the latter for 
gcc-specific code.

I would guess that perhaps people have lifted code from other packages which 
are built with libtool or similar (and hence use '#ifdef PIC'), without 
understanding properly where the definition comes from, and have then pasted 
that code into their own projects that aren't built with libtool. Another 
possibility is that developers see '#ifdef PIC' in many bits of code, and 
assume that's always the way to decide PIC or not.

Thanks,
Kev.