On Mon, Jul 16, 2001 at 11:35:28AM -0700, Josh Coalson wrote:> > The functions themselves, as far as I can tell, only reference data on the > > stack as you say. It is the entry points which are not > > position-independent (though they are relocatable). > > > > I confess to not quite being a wizard at this (yet), but as I understand > > it, shared library code should be position-independent (using relative > > addresses) rather than just relocatable (which could mean that some > > addresses must be patched by the runtime linker). For the calls to be PIC, > > they must be made through an offset stored in the GOT. > > > > There is a section in the NASM manual (8.2 in my copy), titled "Writing > > NetBSD/FreeBSD/OpenBSD and Linux/ELF Shared Libraries" that seems to > > explain how to write position-independent code with NASM. > > I'm still not too clear on all this stuff either. It looks like the only > relevant section of the manual is 8.2.4; I could export the function entry > points that way. But I don't get why this is necessary if the functions are > private to the library. > > Matt, do you think this would be enough to make it work? What kind of errors > (linker?) do you get with the current code?What originally led me to investigate this was that lintian (a tool to check Debian packages for possible problems) reported this error: E: libflac0: shlib-with-non-pic-code usr/lib/libFLAC.so.0.0.0 N: N: The listed shared libraries contain object code that was compiled N: without -fPIC. All object code in shared libraries should be N: recompiled separately from the static libraries with the -fPIC option. N: Another common mistake that causes this problem is linking with ``gcc N: -Wl,-shared'' instead of ``gcc -shared''. N: Refer to Policy Manual, section 11.2 for details. N: This is triggered by the presence of a rel.text section in the shared object as reported by objdump -h: 5 .rel.text 00000020 000030f4 000030f4 000030f4 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA Whereas the rest of the code lives in a plain old .text section. If you look at other shared libraries, like libc, you see no rel.text section, only .text. I believe the rationale for this is that relocation causes the library not to be shared in memory, because different relocations will be necessary when the library is loaded at different locations. This isn't much of an issue for FLAC currently, due to the small number of applications that use it, but it seems like good practice. It is up to you whether or not you feel this is worthwhile; I will deal with the policy compliance issue. As I understand it, non-PIC shared library code doesn't work on other architectures, notably IA64 and PA-RISC, which Debian is currently porting to[0]. This isn't an issue for FLAC, since the ia32 assembler won't be used, but I guess it's something to be kept in mind when writing assembler for other architectures. I'm trying to find other projects which build a shared library using multiplatform assembly to see how they deal with this, but the only one I can find is glibc. They use the GNU assembler, and everything is so tied up in macros that I don't know what's going on yet. [0] By the way, flac seems to segfault early on IA64. When built with --enable-debug, I get a failed assertion: flac 0.10, Copyright (C) 2000,2001 Josh Coalson flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. Type `flac' for details. options: -P 0 -b 4608 -m -l 8 -q 0 -r 3,3 -R 0 -V /home/mdz/english.wav: @@@ FLAC__CPU_UNKNOWN lt-flac: stream_decoder.c:173: FLAC__stream_decoder_init: Assertion `decoder->guts->cpuinfo.use_asm' failed. Aborted -- - mdz
> > > Unfortunately, there is a bigger problem that affects both SDL > > > and FLAC, > > > which is that the assembly routines are not PIC. > > > > It's not? I think all the IA32 code only references data on the > > stack, and > > it doesn't call outside the library or export any functions outside > > the > > library. The only absolute addresses should be the routine entry > > points > > private to the library which I thought were always relocatable. > > The functions themselves, as far as I can tell, only reference data > on the > stack as you say. It is the entry points which are not > position-independent > (though they are relocatable). > > I confess to not quite being a wizard at this (yet), but as I > understand it, > shared library code should be position-independent (using relative > addresses) > rather than just relocatable (which could mean that some addresses > must be > patched by the runtime linker). For the calls to be PIC, they must > be made > through an offset stored in the GOT. > > There is a section in the NASM manual (8.2 in my copy), titled > "Writing > NetBSD/FreeBSD/OpenBSD and Linux/ELF Shared Libraries" that seems to > explain > how to write position-independent code with NASM.I'm still not too clear on all this stuff either. It looks like the only relevant section of the manual is 8.2.4; I could export the function entry points that way. But I don't get why this is necessary if the functions are private to the library. Matt, do you think this would be enough to make it work? What kind of errors (linker?) do you get with the current code? Josh __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
On Mon, Jul 16, 2001 at 06:46:22PM -0400, Matt Zimmerman wrote:> [0] By the way, flac seems to segfault early on IA64. When built with > --enable-debug, I get a failed assertion: > > flac 0.10, Copyright (C) 2000,2001 Josh Coalson > flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are > welcome to redistribute it under certain conditions. Type `flac' for details. > > options: -P 0 -b 4608 -m -l 8 -q 0 -r 3,3 -R 0 -V > /home/mdz/english.wav: > @@@ FLAC__CPU_UNKNOWN > lt-flac: stream_decoder.c:173: FLAC__stream_decoder_init: Assertion `decoder->guts->cpuinfo.use_asm' failed. > AbortedIt looks like this is because FLAC__NO_ASM isn't defined, but should be. configure.in should default to disabling asm optimizations unless the host architecture is one of those that are recognized. -- - mdz
> > > The functions themselves, as far as I can tell, only reference > > > data on the > > > stack as you say. It is the entry points which are not > > > position-independent (though they are relocatable). > > > > > > I confess to not quite being a wizard at this (yet), but as I > > > understand > > > it, shared library code should be position-independent (using > > > relative > > > addresses) rather than just relocatable (which could mean that > > > some > > > addresses must be patched by the runtime linker). For the calls > > > to be PIC, > > > they must be made through an offset stored in the GOT. > > > > > > There is a section in the NASM manual (8.2 in my copy), titled > > > "Writing > > > NetBSD/FreeBSD/OpenBSD and Linux/ELF Shared Libraries" that seems > > > to > > > explain how to write position-independent code with NASM. > > > > I'm still not too clear on all this stuff either. It looks like > > the only > > relevant section of the manual is 8.2.4; I could export the > > function entry > > points that way. But I don't get why this is necessary if the > > functions are > > private to the library. > > > > Matt, do you think this would be enough to make it work? What kind > > of errors > > (linker?) do you get with the current code? > > What originally led me to investigate this was that lintian (a tool > to check > Debian packages for possible problems) reported this error: > > E: libflac0: shlib-with-non-pic-code usr/lib/libFLAC.so.0.0.0 > N: > N: The listed shared libraries contain object code that was > compiled > N: without -fPIC. All object code in shared libraries should be > N: recompiled separately from the static libraries with the -fPIC > option. > N: Another common mistake that causes this problem is linking with > ``gcc > N: -Wl,-shared'' instead of ``gcc -shared''. > N: Refer to Policy Manual, section 11.2 for details. > N: > > This is triggered by the presence of a rel.text section in the shared > object > as reported by objdump -h: > > 5 .rel.text 00000020 000030f4 000030f4 000030f4 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > > Whereas the rest of the code lives in a plain old .text section. If > you look > at other shared libraries, like libc, you see no rel.text section, > only .text. > I believe the rationale for this is that relocation causes the > library not to > be shared in memory, because different relocations will be necessary > when the > library is loaded at different locations. This isn't much of an > issue for FLAC > currently, due to the small number of applications that use it, but > it seems > like good practice. It is up to you whether or not you feel this is > worthwhile; I will deal with the policy compliance issue.I'm not still not sure how to fix this with nasm either. The code is declared in the .text segment, and emitted to the .text segment in the .o file, but upon linking ends up in .rel.text. I think I will put this off until after 1.0. One thing I did noticed is that the CFLAGS are not specifying -fPIC right now. Matt, are you planning to build a C-only version of the shared library? In this case it would make sense to add -fPIC to the options. Josh __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/