Menu

#533 libmp3lame.so contains TEXTRELs with NASM 2.09

closed-out-of-date
nobody
None
5
2014-08-11
2011-03-26
No

Hi,

LAME 3.98.4 uses nasm to compile some assembly code, code that is PIC-friendly.

With NASM 2.09 and later, during the linking stage, the resultant libmp3lame.so file ends up with TEXTREL segments and thus isn't fully PIC. I've tested this on both Linux and Solaris 10.

On linux, the GNU linker will link the objects without complaining, but on Solaris 10, the default Solaris linker won't even go that far:

gcc -shared -Wl,-h -Wl,libmp3lame.so.0 -o .libs/libmp3lame.so.0.0.0 .libs/VbrTag.o .libs/bitstream.o .libs/encoder.o .libs/fft.o .libs/gain_analysis.o .libs/id3tag.o .libs/lame.o .libs/newmdct.o .libs/presets.o .libs/psymodel.o .libs/quantize.o .libs/quantize_pvt.o .libs/reservoir.o .libs/set_get.o .libs/tables.o .libs/takehiro.o .libs/util.o .libs/vbrquantize.o .libs/version.o .libs/mpglib_interface.o -Wl,-z -Wl,allextract ../libmp3lame/i386/.libs/liblameasmroutines.a ../libmp3lame/vector/.libs/liblamevectorroutines.a ../mpglib/.libs/libmpgdecoder.a -Wl,-z -Wl,defaultextract -lm -lsocket -lnsl -lc -maccumulate-outgoing-args
Text relocation remains referenced
against symbol offset in file
<unknown> 0x6e ../libmp3lame/i386/.libs/liblameasmroutines.a(choose_table.o)
<unknown> 0x75 ../libmp3lame/i386/.libs/liblameasmroutines.a(choose_table.o)
<unknown> 0x9a ../libmp3lame/i386/.libs/liblameasmroutines.a(choose_table.o)
<unknown> 0xa1 ../libmp3lame/i386/.libs/liblameasmroutines.a(choose_table.o)
<unknown> 0xa8 ../libmp3lame/i386/.libs/liblameasmroutines.a(choose_table.o)
<unknown> 0x12b ../libmp3lame/i386/.libs/liblameasmroutines.a(choose_table.o)
<unknown> 0x133 ../libmp3lame/i386/.libs/liblameasmroutines.a(choose_table.o)
<unknown> 0x1a0 ../libmp3lame/i386/.libs/liblameasmroutines.a(choose_table.o)
<unknown> 0x1aa ../libmp3lame/i386/.libs/liblameasmroutines.a(choose_table.o)
<unknown> 0x1b4 ../libmp3lame/i386/.libs/liblameasmroutines.a(choose_table.o)
<unknown> 0x1c2 ../libmp3lame/i386/.libs/liblameasmroutines.a(choose_table.o)
<unknown> 0x24c ../libmp3lame/i386/.libs/liblameasmroutines.a(choose_table.o)
<unknown> 0x25d ../libmp3lame/i386/.libs/liblameasmroutines.a(choose_table.o)
<unknown> 0x39 ../libmp3lame/i386/.libs/liblameasmroutines.a(fft3dn.o)
<unknown> 0x56 ../libmp3lame/i386/.libs/liblameasmroutines.a(fft3dn.o)
<unknown> 0x128 ../libmp3lame/i386/.libs/liblameasmroutines.a(fft3dn.o)
<unknown> 0x142 ../libmp3lame/i386/.libs/liblameasmroutines.a(fft3dn.o)
<unknown> 0x26e ../libmp3lame/i386/.libs/liblameasmroutines.a(fft3dn.o)
<unknown> 0x2b9 ../libmp3lame/i386/.libs/liblameasmroutines.a(fft3dn.o)
<unknown> 0x2d6 ../libmp3lame/i386/.libs/liblameasmroutines.a(fft3dn.o)
<unknown> 0x398 ../libmp3lame/i386/.libs/liblameasmroutines.a(fft3dn.o)
<unknown> 0x4ce ../libmp3lame/i386/.libs/liblameasmroutines.a(fft3dn.o)
<unknown> 0x2c ../libmp3lame/i386/.libs/liblameasmroutines.a(fftsse.o)
<unknown> 0x7a ../libmp3lame/i386/.libs/liblameasmroutines.a(fftsse.o)
<unknown> 0x88 ../libmp3lame/i386/.libs/liblameasmroutines.a(fftsse.o)
<unknown> 0xc4 ../libmp3lame/i386/.libs/liblameasmroutines.a(fftsse.o)
<unknown> 0xd9 ../libmp3lame/i386/.libs/liblameasmroutines.a(fftsse.o)
<unknown> 0xe7 ../libmp3lame/i386/.libs/liblameasmroutines.a(fftsse.o)
<unknown> 0x1d0 ../libmp3lame/i386/.libs/liblameasmroutines.a(fftsse.o)
<unknown> 0x1e4 ../libmp3lame/i386/.libs/liblameasmroutines.a(fftsse.o)
<unknown> 0x20b ../libmp3lame/i386/.libs/liblameasmroutines.a(fftsse.o)
<unknown> 0x219 ../libmp3lame/i386/.libs/liblameasmroutines.a(fftsse.o)
t1l 0x189 ../libmp3lame/i386/.libs/liblameasmroutines.a(choose_table.o)
largetbl 0xde ../libmp3lame/i386/.libs/liblameasmroutines.a(choose_table.o)
largetbl 0x105 ../libmp3lame/i386/.libs/liblameasmroutines.a(choose_table.o)
largetbl 0x10f ../libmp3lame/i386/.libs/liblameasmroutines.a(choose_table.o)
table23 0x245 ../libmp3lame/i386/.libs/liblameasmroutines.a(choose_table.o)
table56 0x256 ../libmp3lame/i386/.libs/liblameasmroutines.a(choose_table.o)
ld: fatal: relocations remain against allocatable but non-writable sections
collect2: ld returned 1 exit status

On Linux with GNU ld you can see the text rel:

alasdair ~ (linux01): readelf -d /opt/lame/lib/libmp3lame.so

Dynamic section at offset 0x476b4 contains 23 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000e (SONAME) Library soname: [libmp3lame.so.0]
0x0000000c (INIT) 0x5a14
0x0000000d (FINI) 0x3cd44
0x6ffffef5 (GNU_HASH) 0xb4
0x00000005 (STRTAB) 0x2888
0x00000006 (SYMTAB) 0xd38
0x0000000a (STRSZ) 7290 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000003 (PLTGOT) 0x47834
0x00000002 (PLTRELSZ) 1488 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x5444
0x00000011 (REL) 0x48cc
0x00000012 (RELSZ) 2936 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x00000016 (TEXTREL) 0x0
0x6ffffffe (VERNEED) 0x486c
0x6fffffff (VERNEEDNUM) 2
0x6ffffff0 (VERSYM) 0x4502
0x6ffffffa (RELCOUNT) 282
0x00000000 (NULL) 0x0

If one uses a version of nasm older than 2.09 (such as 2.08, 2.06, 2.01 or 0.99.06), no TEXTREL will be present in the resultant library:

alasdair ~ (linux01): readelf -d /opt/lame-nasm-2.08/lib/libmp3lame.so

Dynamic section at offset 0x476b4 contains 22 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000e (SONAME) Library soname: [libmp3lame.so.0]
0x0000000c (INIT) 0x58e4
0x0000000d (FINI) 0x3cca4
0x6ffffef5 (GNU_HASH) 0xb4
0x00000005 (STRTAB) 0x2888
0x00000006 (SYMTAB) 0xd38
0x0000000a (STRSZ) 7290 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000003 (PLTGOT) 0x4782c
0x00000002 (PLTRELSZ) 1488 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x5314
0x00000011 (REL) 0x48cc
0x00000012 (RELSZ) 2632 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffe (VERNEED) 0x486c
0x6fffffff (VERNEEDNUM) 2
0x6ffffff0 (VERSYM) 0x4502
0x6ffffffa (RELCOUNT) 250
0x00000000 (NULL) 0x0

alasdair ~ (linux01): readelf -d /opt/lame-nasm-2.09/lib/libmp3lame.so | grep TEXTREL
0x00000016 (TEXTREL) 0x0
alasdair ~ (linux01): readelf -d /opt/lame-nasm-2.08/lib/libmp3lame.so | grep TEXTREL
alasdair ~ (linux01): readelf -d /opt/lame-nasm-2.06/lib/libmp3lame.so | grep TEXTREL
alasdair ~ (linux01): readelf -d /opt/lame-nasm-2.01/lib/libmp3lame.so | grep TEXTREL
alasdair ~ (linux01): readelf -d /opt/lame-nasm/lib/libmp3lame.so | grep TEXTREL
alasdair ~ (linux01): readelf -d /opt/lame-nasm-0.99.06/lib/libmp3lame.so | grep TEXTREL
alasdair ~ (linux01):

So there appears to be an issue with the object generation with nasm 2.09 and later. I've tried this with 2.10rc4 and its still present as an issue:

alasdair ~ (linux01): readelf -d /opt/lame-nasm2.10rc4/lib/libmp3lame.so | grep TEXT
0x00000016 (TEXTREL) 0x0

I can provide any other information as needed. It is possible the assembly code lame is using is incorrect somehow and nasm 2.09 brings this to light, but I'm not an assembly coder so can't comment there :-)

Thanks for your help!

Cheers,

Alasdair

Discussion

  • Cyrill Gorcunov

    Cyrill Gorcunov - 2011-03-26

    Thanks for report, Alasdair! I'll take a look as only time permits.

     
  • H. Peter Anvin

    H. Peter Anvin - 2011-03-26

    I notice the TEXTREL section is actually empty. It would be highly useful to understand what is the difference in the .o files. This looks like 32-bit code, so this is probably an bug introduced with ELF unification.

     
  • Nobody/Anonymous

    i'll try to find some time tomorrow, sorry guys for delay :(

     
  • Nobody/Anonymous

    Btw Alasdair, could you provide some small asm code snippet where this issue happens, compiling the whole lame is not that convenient ;)

     
  • Nobody/Anonymous

    hmm, can;t repeat on x86-64 host, probably related on type of host nasm is built on, will report as only get some more details...

     
  • Nobody/Anonymous

    ok, i've fixed this issue, hope to release new stable tonight.

     
  • Nobody/Anonymous

    should be fixed in 2.09.08, please try it out, thanks!

     
  • Cyrill Gorcunov

    Cyrill Gorcunov - 2011-05-13
    • status: open --> closed-out-of-date
     
  • Cyrill Gorcunov

    Cyrill Gorcunov - 2011-05-13

    Since there is no feedback from the reporter, I close this bug as being out of date. The issue has been fixed I hope. If there some problems still -- feel free to open a new entry. Thanks!

     

Log in to post a comment.