Symbol weirdness on SCO OSR5

Symbol weirdness on SCO OSR5

[J. Kean Johnston]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

Hi all.

Just noticed a distrurbing difference between GCC 2.7.2.1 and egcs (and
gcc 2.8.0 snapshots too). I noticed it while trying to compile XFree86 on
SCO Open Server 5. When compiling with egcs or gcc2.8, I get the following
error when trying to create the dynamic version of libXaw.so:
fatal error: relocations remain against allocatable but non-writable
section: .text

This is becuase ld is being invoked with -z text. It bleats about the
symbols in Panner.o. For reference, I have included the object files
generated by both egcs and the old gcc2.7.2.1, as well as objdump
disassembly and objump --reloc.

Any clues?

JKJ

[-- Attachment #2: badsyms.t.gz --]
[-- Type: application/x-gzip, Size: 44853 bytes --]

Re: Symbol weirdness on SCO OSR5

[Jeffrey A Law]

  In message < Pine.SCO.3.96.970901165458.23189A-101000@hyperion.pdev.sco.com >you write:
  > SCO Open Server 5. When compiling with egcs or gcc2.8, I get the following
  > error when trying to create the dynamic version of libXaw.so:
  > fatal error: relocations remain against allocatable but non-writable
  > section: .text
  > 
  > This is becuase ld is being invoked with -z text. It bleats about the
  > symbols in Panner.o. For reference, I have included the object files
  > generated by both egcs and the old gcc2.7.2.1, as well as objdump
  > disassembly and objump --reloc.
  > 
Did it complain about any particular symbols?  If so, are those symbols
stuff normally found in libgcc.a?  That would indicate a missing -fpic/-fPIC
when building libgcc.

jeff

Re: Symbol weirdness on SCO OSR5

[Robert Lipe]

>   > error when trying to create the dynamic version of libXaw.so:
>   > fatal error: relocations remain against allocatable but non-writable
>   > section: .text

I haven't seen this specific problem, so I didn't comment at first.  I 
have a feeling this is one of these things that I probably won't be able
to figure out, but I can at least play eyes and fingers for someone that
does understand the specs/multilibbing stuff.

Oh.   It's worth disclaiming that Kean and I are likely both using 
the multilib patches (I know I am) he submitted a week or two ago 
instead of what's actually in the tree becuase it fixes so many 
problems for us.   So if you look at *sco5* and don't see multilibbing
stuff, that's why.


> Did it complain about any particular symbols?  If so, are those symbols
> stuff normally found in libgcc.a?  That would indicate a missing -fpic/-fPIC
> when building libgcc.

Jeff might be onto something here.   When building the stuff that lands
in libgcc2.a (that would be the ELF one), the compile looks something like:

for name in _muldi3 _divdi3 _moddi3 _udivdi3 _umoddi3 _negdi2 _lshrdi3 _ashldi3
_ashrdi3 _ffsdi2 _udiv_w_sdiv _udivmoddi4 _cmpdi2 _ucmpdi2 _floatdidf _floatdisf
 _fixunsdfsi _fixunssfsi _fixunsdfdi _fixdfdi _fixunssfdi _fixsfdi _fixxfdi _fix
unsxfdi _floatdixf _fixunsxfsi _fixtfdi _fixunstfdi _floatditf __gcc_bcmp _varar
gs __dummy _eprintf _op_new _op_vnew _new_handler _op_delete _op_vdel _bb _shtab
 _clear_cache _trampoline __main _exit _ctors _eh  _pure; \
do \
  echo ${name}; \
  ./xgcc -B./ -O2   -DIN_GCC    -g -I./include   -g1 -DIN_LIBGCC2 -D__GCC_FLOAT_
NOT_NEEDED  -I. -I../../egcs-970901/gcc -I../../egcs-970901/gcc/config -c -DL${n
ame} \
      ../../egcs-970901/gcc/libgcc2.c -o ${name}.o; \
  if [ $? -eq 0 ] ; then true; else exit 1; fi; \
  ar rc tmplibgcc2.a ${name}.o; \
  rm -f ${name}.o; \
done
_muldi3


Note the absence of -fPIC.  It's also not present when (e.g.) tinfo.cc and
friends are built for ELF.

The COFF build (-mcoff) comes along and doesn't use -fPIC either, of course.


Interestingly, if I remove stmp-crtS and crt*.o, and force a rebuild of
those files, it does use -PIC to build crtbegin.o and crtend.o (ELF) but
not crtendS.o and crtbeginS.o (COFF) which does seem to mirror what I think
Jeff says is desirable.

So, if you really think this is likely the problem, how do we get 
the multilibbed code to build the ELF version of libgcc.a with 
-fPIC and not pass this to the COFF version?

Thanx, 
RJL

Re: Symbol weirdness on SCO OSR5

[Jeffrey A Law]

  In message < 19970905160121.05398@dgii.com >you write:
  > Oh.   It's worth disclaiming that Kean and I are likely both using 
  > the multilib patches (I know I am) he submitted a week or two ago 
  > instead of what's actually in the tree becuase it fixes so many 
  > problems for us.   So if you look at *sco5* and don't see multilibbing
  > stuff, that's why.
Kean -- What the status on the copyright papers for this stuff?  I'd like
to see it go in, but we can't install it without papers.

If you've sent them, then I can bug the FSF folks to find out what's
going on.  If you haven't sent them, let me know when you do.


  > So, if you really think this is likely the problem, how do we get 
  > the multilibbed code to build the ELF version of libgcc.a with 
  > -fPIC and not pass this to the COFF version?
I think the way to do this is with something like
MULTILIB_OPTIONS = pic/coff ...

Which should indicate that pic & coff don't go together.

jeff

Re: Symbol weirdness on SCO OSR5

[Jim Wilson]

I took a look at this, and I noticed in the egcs.reloc file, in the .text
section you have:
00000824 R_386_32          __ctype

I believe that this is not a valid relocation type for the text section.
This relocation seems to be the only one that has the wrong type.

I can't tell what is wrong from looking at the egcs.od file.  It seems
to be a relocation in this instruction, but that doesn't tell me anything
useful.
     822:       f0 bf 01 00 00  lock movl $0x1,%edi

You might try looking at the .s file produced from compiling the file Panner.c.
There will probably be something obviously wrong here if you know what to
look for.  I think that references to globals are all supposed to have
@GOT/@GOTOFF/@PLT appended to the end of the symbol name, so if you find
a reference to __ctype that is missing this suffix, then that is the problem.

Jim