Neden tüm kod derlenmiş konum bağımsız değil?


87

Paylaşılan kitaplıkları gcc'de derlerken -fPIC seçeneği kodu konumdan bağımsız olarak derler. Tüm kod konumlarını bağımsız olarak derlememenizin herhangi bir nedeni (performans veya başka türlü) var mı?


2
Ancak wowest tamamen doğru değil. Birçok işlev çağrısı ve atlama, göreceli atlamaları kullanır, böylece hareket ettirildikten sonra bir atlama tablosuna bile ihtiyaç duymazlar.
Unknown

Oluşturulan derleme koduna bakıldığında, işlevin adresinin yüklendiği, ancak fpic olmayan kodun yalnızca bir sıçrama olduğu görülüyor. İfadenizi yanlış mı anlıyorum?
ojblass

@ojblass demek istediğim, bazı atlamaların "0x400000'e atla" yerine "50 talimatı buradan ileriye atla" veya "5 talimatı geriye atla" gibi olduğu. Yani her seferinde -fPIC ile bir adres yüklemeniz gerektiğini söylemek tamamen doğru değildir.
Bilinmeyen

Wikipedia makalesi iyi bir açıklama sağlar. Temel olarak, bazı mimarilerde göreceli bir adrese atlamanın doğrudan bir yolu yoktur. Bu nedenle, PIC'in bu yaylarda kullanılması daha pahalıdır. Daha fazla bilgi için @ EvanTeran'ın cevabına bakın.
Alexei Sholik

Yanıtlar:


68

Bir yönlendirme ekler. Konumdan bağımsız kodla, işlevinizin adresini yüklemeniz ve ardından ona atlamanız gerekir. Normalde, fonksiyonun adresi komut akışında zaten mevcuttur.


33

Bu makale, PIC'in nasıl çalıştığını açıklar ve onu alternatif yükleme süresi yer değiştirmeyle karşılaştırır . Sorunuzla alakalı olduğunu düşünüyorum.


16
@Nick: Katılmıyorum. Soruyu sorana yardımcı oluyorsa, yanıttır. İlgili bir veya iki makaleye işaret etmek çok sayıda bilgi sağlayabilir.
Eli Bendersky

5
Bu yazıda sonuç yok, sadece bir makaleye bağlantı var. Performans sorunları nedeniyle PIC'in varsayılan olarak kullanılmadığına dair bir ipucu bile yok.
Nick

10
Bu bağlantı soruyu cevaplayabilirken, cevabın temel kısımlarını buraya eklemek ve referans için bağlantıyı sağlamak daha iyidir. Bağlantılı sayfa değişirse yalnızca bağlantı yanıtları geçersiz hale gelebilir.
Rob

4
@ Rob: Üretken olan şey bir düzenleme önermek ve sızlanmak için yorum kullanmak değil. Bu cevap 4 yaşında. O zamanlar SO'nun bir cevabın nasıl görünmesi gerektiği konusunda daha az katı kuralları vardı
Eli Bendersky

6
Bu gönderi "inceleme" altında göründü ve bunu yapmamı istedim ve yaptım. Başka biri işaretledi. "Ağlayan yorum" otomatik olarak ben değil, SO tarafından üretiliyor.
Rob

27

Evet, performans nedenleri var. Bazı erişimler, bellekteki mutlak konumu elde etmek için etkin bir şekilde başka bir yönlendirme katmanı altındadır.

Global değişkenlerin ofsetlerini saklayan GOT (Global ofset tablosu) da vardır. Bana göre bu, wikipedia ve diğer birkaç kaynak tarafından konuma bağlı olarak sınıflandırılan bir IAT düzeltme tablosuna benziyor.

http://en.wikipedia.org/wiki/Position_independent_code


23

Kabul edilen cevaba ek olarak. PIC kod performansına çok zarar veren bir şey, x86'da "IP'ye göre adresleme" olmamasıdır. "IP'ye göre adresleme" ile mevcut komut işaretçisinden X bayt olan verileri isteyebilirsiniz. Bu, PIC kodunu çok daha basit hale getirir.

Atlamalar ve çağrılar genellikle EIP'ye bağlıdır, bu nedenle bunlar gerçekten bir sorun oluşturmaz. Bununla birlikte, verilere erişmek biraz ekstra hile gerektirecektir. Bazen bir kayıt, kodun gerektirdiği verilere geçici olarak bir "temel işaretçi" olarak ayrılacaktır. Örneğin, yaygın bir teknik, çağrıların x86'da çalışma şeklini kötüye kullanmaktır:

Bu ve diğer teknikler, veri erişimlerine bir dolaylılık katmanı ekler. Örneğin, gcc derleyicileri tarafından kullanılan GOT (Global ofset tablosu).

x86-64, işleri çok daha basit hale getiren bir "RIP göreli" modu ekledi .


1
IIRC MIPS, göreceli sıçramalar dışında PC'ye göre adreslemeye de sahip değil
phuclv

1
Bu, çalıştırdığı adresi almak için shellcode'da kullanılan yaygın bir tekniktir. Bunu birkaç CTF çözümünde kullandım.
sherrellbc

2

Çünkü tamamen konumdan bağımsız kod uygulamak, kod üretecine daha hızlı işlemlerin kullanılmasını engelleyebilecek bir kısıtlama ekler veya bu kısıtlamayı korumak için fazladan adımlar ekleyebilir.

Bu, birbirlerinin belleğini işgal etmeyecek süreçlere güvendiğiniz ve herhangi bir temel adreste belirli bir uygulamayı yüklemeniz gerekebileceği bir sanal bellek sistemi olmadan çoklu işlemeyi elde etmek için kabul edilebilir bir takas olabilir.

Pek çok modern sistemde performans ödünleşmeleri farklıdır ve yer değiştiren bir yükleyici genellikle daha ucuzdur (kodun ilk yüklendiği her zaman maliyeti vardır), bir optimize edicinin serbest saltanatı varsa yapabileceği en iyisinden daha ucuzdur. Ayrıca, sanal adres alanlarının mevcudiyeti, ilk etapta konum bağımsızlığı motivasyonunun çoğunu gizler.


1

Ayrıca, çoğu modern işlemcideki sanal bellek donanımı (çoğu modern işletim sistemi tarafından kullanılır), çok sayıda kodun (mmap veya benzerinin ilginç kullanımı dışında tüm kullanıcı alanı uygulamaları) konumdan bağımsız olması gerekmediği anlamına gelir. Her program, sıfırdan başladığını düşündüğü kendi adres alanını alır.


4
Ancak aynı .so kitaplığının farklı yürütülebilir dosyalar tarafından kullanıldığında belleğe yalnızca bir kez yüklenmesini sağlamak için bir VM-MMU PIC koduyla bile gereklidir.
mmmmmmmm

1

position-independent code Ekstra bir kayıt gerektirdiği için çoğu mimaride bir performans ek yükü vardır.

Yani, bu performans amaçlıdır.


0

Günümüzde işletim sistemi ve derleyici varsayılan olarak tüm kodu konumdan bağımsız kod yapar. -FPIC bayrağı olmadan derlemeyi deneyin, kod iyi derlenir, ancak yalnızca bir uyarı alırsınız. OS benzeri pencereler bunu başarmak için bellek eşleme adı verilen bir teknik kullanır.


-5

Soru 2009'a tarihleniyor. On yıl geçti ve şimdi tüm kodlar aslında konumdan bağımsız. Bu artık işletim sistemleri ve derleyiciler tarafından uygulanmaktadır. Vazgeçmenin bir yolu yok. Tüm kod PIE ile zorla derlenir ve bu ASLR bahanesinin bir parçası olarak -no-pic / -no-pasta bayrağı göz ardı edilmektedir. Bunun nedeni, eskiden hızlı uygulamaları yavaşlatmak ve artırılmış güvenlik kisvesi altında daha yeni donanımlar satmaktır. Bu tamamen mantıksız, çünkü artık büyük bellek boyutları, tüm uygulamaları statik olarak derleyerek dinamik bağlantıların cehenneminden kurtulmamızı sağlıyor.

Aynı şey daha önce insanlar sessizce gerçek modu ve diğer özgürlüklerin ellerinden alınmasını kabul ettiklerinde oldu. Ve umursuyorum, MMU bağlam anahtarları ve adres çeviri gecikmesi nedeniyle ağır bir yavaşlama yaşıyor. Bilim adamlarının fizik deneylerini örneklemek için kullandıkları gibi performans açısından kritik sistemlerde MMU bulamazsınız.

Şikayet etmiyorsunuz, çünkü kodunuzun tüm bu eğitim çarkları tarafından engellendiğini bile bilmiyorsunuz. Ne söyleyebilirim? Şimdi PIC'leriyle 2 kat daha yavaş yazılımın keyfini çıkarın! Dahası, LLVM'nin gelişiyle, yakında x86 satır içi derlemesine erişimi olmayan zorunlu JIT (yönetilen kod) olacak ve bu da herhangi bir C / C ++ kodunu daha da yavaşlatacaktır. "Güvenlik için özgürlüğü feda edenler ikisini de hak etmiyor."


Bu sadece gerçeklerin bir ifadesidir: 10 yıl önce PIC isteğe bağlıydı, ancak bugün varsayılan ve zorunludur. PIE olmayan kodun sonraki işletim sistemi sürümlerinde destekleneceğinden şüpheliyim. Tıpkı Windows 9x'ten sonra gerçek mod desteğinin bırakılması gibi. Dolayısıyla, işletim sisteminizin kilidini bir şekilde açıp desteği yeniden etkinleştirmediğiniz sürece, PIC kullanıp kullanmama sorusu daha teorik bir bilgisayar bilimi konusu haline gelir. İnsanların PIC hakkında bilmesi gereken en önemli şey, derleyicilerin şimdiye kadar statik derlemeyi destekleyecek kadar yavaş olması ve çoğu DLL'nin statik sürümlerinin mevcut olmasıdır.
SmugLispWeenie

2
İlk birkaç cümleniz sadece gerçeklerin bir ifadesidir. Geri kalanı, komplo sınırındaki fikirdir.
Mitch Lindgren

Peki, sadece insanlarla konuşun, bu konuda fikirlerini sorun. Ben şahsen, PIC ile non-PIC'in de bir ideoloji meselesi haline geldiğini buldum. PIC, kodun toplu olarak üretildiği ve herkesin aynı kopyayı aldığı Komünizmin programlama eşdeğeridir. Non-PIC, aynı kodun birçok rakip versiyonunun bulunduğu Kapitalizmin programlama eşdeğeridir. Bu yüzden daha solcu zihniyete sahip insanlar, en sevdikleri ideolojinin en azından bilgi işlemde işe yarayabileceğini kanıtlamak için bilinçaltında PIC'i destekliyorlar. Aynı kişiler, kişisel olarak değiştirilmiş libpng kullanmamanızı tavsiye ederler.
SmugLispWeenie

3
Bir programlama web sitesinde siyasi
sözler olamaz
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.