Discussion:
[Mingw-w64-public] Position independent code (-fPIC) on x86_64 Windows dll specially for Cygwin
dashesy
2012-08-08 16:13:44 UTC
Permalink
Reading the Wikipedia page
(http://en.wikipedia.org/wiki/Position-independent_code) , it seems
Windows supports PIC on x64,
Please correct me if I am wrong.
I was wondering if I can build PIC dlls on x64.
This would be specially useful with "--enable-cygwin" to eliminate the
need to do rebaseall at least on x64 platform and avoid the fork
failures.

Thanks
dashesy
Kai Tietz
2012-08-08 16:18:24 UTC
Permalink
Post by dashesy
Reading the Wikipedia page
(http://en.wikipedia.org/wiki/Position-independent_code) , it seems
Windows supports PIC on x64,
Please correct me if I am wrong.
I was wondering if I can build PIC dlls on x64.
This would be specially useful with "--enable-cygwin" to eliminate the
need to do rebaseall at least on x64 platform and avoid the fork
failures.
Thanks
dashesy
Well, you are right that x64 allows PIC in gcc. But you have to be
aware that even cygwin, and 32-bit native Windows images are *position
independent*. Just in comparison to ELF the Windows PE(+)-COFF
format is always a finally linked image. So PIC has here a different
meaning, as shared objects are pretty different.

Hope this helps,
Kai
dashesy
2012-08-08 17:33:30 UTC
Permalink
Post by Kai Tietz
Post by dashesy
Reading the Wikipedia page
(http://en.wikipedia.org/wiki/Position-independent_code) , it seems
Windows supports PIC on x64,
Please correct me if I am wrong.
I was wondering if I can build PIC dlls on x64.
This would be specially useful with "--enable-cygwin" to eliminate the
need to do rebaseall at least on x64 platform and avoid the fork
failures.
Thanks
dashesy
Well, you are right that x64 allows PIC in gcc. But you have to be
aware that even cygwin, and 32-bit native Windows images are *position
independent*. Just in comparison to ELF the Windows PE(+)-COFF
format is always a finally linked image. So PIC has here a different
meaning, as shared objects are pretty different.
Hope this helps,
Kai
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Thanks for the answer; is there any reference that I can read further?
I do not understand if they are position independent why loader might
rebase them on load.

BTW, this is the line in Wikipedia "64-bit Windows has switched to
using position-independent code for DLLs as well and has abandoned
relocation"
And it references here: http://msdn.microsoft.com/en-us/magazine/bb985017.aspx

Thanks again
dashesy
Earnie Boyd
2012-08-08 17:37:05 UTC
Permalink
Post by dashesy
BTW, this is the line in Wikipedia "64-bit Windows has switched to
using position-independent code for DLLs as well and has abandoned
relocation"
And it references here: http://msdn.microsoft.com/en-us/magazine/bb985017.aspx
For 64 bit binaries. Not for 32 bit binaries running in the emulator.
But does binutils support it for 64 bit binaries?
--
Earnie
-- https://sites.google.com/site/earnieboyd
dashesy
2012-08-08 18:30:47 UTC
Permalink
On Wed, Aug 8, 2012 at 11:37 AM, Earnie Boyd
Post by Earnie Boyd
Post by dashesy
BTW, this is the line in Wikipedia "64-bit Windows has switched to
using position-independent code for DLLs as well and has abandoned
relocation"
And it references here: http://msdn.microsoft.com/en-us/magazine/bb985017.aspx
For 64 bit binaries. Not for 32 bit binaries running in the emulator.
But does binutils support it for 64 bit binaries?
That is the better way of asking my question.
Does binutils support it for 64-bit binaries, if yes it might give
-fPIC a new meaning (no longer a warning)
Post by Earnie Boyd
--
Earnie
-- https://sites.google.com/site/earnieboyd
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-w64-public mailing list
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Thanks
dashesy
Kai Tietz
2012-08-08 18:39:03 UTC
Permalink
Post by dashesy
On Wed, Aug 8, 2012 at 11:37 AM, Earnie Boyd
Post by Earnie Boyd
Post by dashesy
BTW, this is the line in Wikipedia "64-bit Windows has switched to
using position-independent code for DLLs as well and has abandoned
relocation"
And it references here: http://msdn.microsoft.com/en-us/magazine/bb985017.aspx
For 64 bit binaries. Not for 32 bit binaries running in the emulator.
But does binutils support it for 64 bit binaries?
That is the better way of asking my question.
Does binutils support it for 64-bit binaries, if yes it might give
-fPIC a new meaning (no longer a warning)
Sure, x64 has PC-relocations. If binutils wouldn't support
PC-relative relocations we wouldn't have x64 support at all.
Sorry, I don't get the meaning here. Nevertheless PE-COFF might
have base-relocations even for 64-bit. But those are handled by
loader. To avoid these complete you need to avoid some
language-constructs, nevertheless the IAT tables are aways fixed-bound
to a specific address of imported module. If you have further
question about how PE(+)-COFF works, I recomment that you read the
pe-coff specification, which can be found on msdn for download.

Regards,
Kai

Loading...