From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 12 Nov 2003 18:07:06 +0300 From: "Dmitry V. Levin" To: ALT Devel discussion list Subject: Re: [devel] IA: eliminating TEXTRELocations Message-ID: <20031112150706.GA21043@basalt.office.altlinux.org> Mail-Followup-To: ALT Devel discussion list References: <20031108155731.GA21473@basalt.office.altlinux.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: X-fingerprint: 9658 398D 181B 1200 8FC5 26B8 F6F8 846B C1E2 3429 X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.3 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 15:07:08 -0000 Archived-At: List-Archive: List-Post: --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Wed, Nov 12, 2003 at 06:50:56PM +0300, Vitaly Lugovsky wrote: > On Sat, 8 Nov 2003, Dmitry V. Levin wrote: > > > Greetings! > > > > Оказывается, к сожалению, большинство программистов, создающих > > разделяемые библиотеки (DSO), относится к этой работе слишком > > легкомысленно и не учитывает рекомендации специалистов. > > Надо бы помнить, что шаренные объекты разное назначение имеют. > Это и именно *разделяемая* библиотека, тогда всё сказанное > справедливо, и ПЛАГИН, и просто *динамически подгружаемая* > библиотека. Оно же всё равно разделяемое, т.е. может быть использовано одновременно несколькими процессами. Разница только в способе загрузки. > > "Самое главное - всегда использовать параметры -fpic либо > > -fPIC при > > порождении кода, который в конечном итоге попадёт в DSO. > > Если компилятор вообще знает про PIC-код, если платформа не > предусматривает НЕПРОСТИТЕЛЬНЫЙ оверхед на PIC-код, и т.п. Это всё общие слова. > > Эта > > рекомендация применима в равной степени как к коду, так и к > > данным. Код, > > который не был скомпилирован таким образом, будет содержать > > text > > relocations. Этому нет оправдания. > > Есть. На дебильных x86 это дикий оверхед. Один регистр общего > назначения - коту под хвост. При том, что их на этом > калькуляторе-переростке и так не богато. Поскольку мы всё равно не можем исправить эту платформу (x86), то критиковать её сейчас не имеет смысла. Компилятор (например, gcc) умеет оптимизировать использование этого самого регистра. > > Аргументы, базирующиеся на утверждении, что код не является > > разделяемым > > потому, что другие процессы не используют этот DSO, не верны. > > Чушь религиозная. Тем не менее это так. > > В таком случае вообще нет смысла использовать DSO; соответствующий код > > следует просто собирать в составе приложения." > > Дабы таскать бинарники по 5метров? Нюню. А ведь ещё и плагины > бывают. Тогда их надо собирать правильно. > > lablGL-1.00-alt1 > > ocaml-mysql-1.0.1-alt1 > > ocaml-postgres-20010808-alt11s > > ocamlgsl-0.2.2-alt3 > > ocamlnet-0.96-alt4s > > pcre-ocaml-4.28.3-alt5s > > pxp-1.1.94-alt3s > .. > > > Я внедрил проверку на TEXTREL в verify_elf очередной версии > > rpm-build. > > По умолчанию она будет включена. > > НЕ НАДО! Пусть по умолчанию relaxed выключает обе проверки. > А то всё ocaml-хозяйство опять пересобирать... Я могу сделать так, чтобы relaxed отключал обе проверки. > > Чтобы ослабить проверку обоих параметров, можно использовать > > новую форму > > выражения > > %set_verify_elf_method rpath=relaxed,textrel=relaxed > > > > Разумеется, ослаблять проверки, включённые по умолчанию, не > > рекомендуется. > > Кю... Huh? -- ldv --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/skya9viEa8HiNCkRAqH6AJ9dS+s+p1Iwsqm15Rl5mvsFWa0tMACfXmvW xVYSQGu77HFVSx9dBwOCMNQ= =QWEL -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6--