> > libtool would not link the "plain" nasm-generated object files for > > the i386 > > assembly optimizations. I've patched src/libFLAC/i386/Makefile.am > > to operate > > similarly to the automake file used for the SDL assembly routines. > > > > I saw a post to the FLAC mailing list saying that automake expects > > the suffix > > to be .s, so .nasm files were renamed to .s files. automake can be > > told to > > accept other suffixes using the SUFFIXES variable. libtool > > recognizes files > > with .asm suffixes, so I renamed .s files to .asm files. > > 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. Josh __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
On Tue, Jul 10, 2001 at 03:27:05PM -0700, Josh Coalson wrote:> > 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. -- - 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/