Re: Checks-syms results

[Jeff Bailey]

On Sat, Feb 23, 2002 at 07:03:14PM -0500, Roland McGrath wrote:

> Thanks for doing this.

Any time. =)

> > You may want me to rerunit with more binaries, though.

> As many as you can, please.  In examining the results I realized that the
> script is not showing all relevant symbols, because data references wind up
> with defined symbols.  I'm attaching a new version of the script that shows
> these too.

> > You can find the report at: http://people.debian.org/~jbailey/check_syms.txt

I've rerun the script on the current set of installed binaries, so
that you have the information for now.  I will attempt to build a few
more over the weekend. (making sure that I'm diverse with different
types of applications)

http://people.debian.org/~jbailey/check_syms-200202231911.txt

> We need to figure out what used the GLIBC_2.0 set.  Nothing should.
> It might be some libgcc code or something like that.

libgcc_s.so.1 appears to have it.  I suspect it's from the file
gcc-3.0.3/gcc/config/libgcc-glibc.ver

Here's the objdump -p from the library:

/gnu/lib/libgcc_s.so.1:     file format elf32-i386

Program Header:
    LOAD off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12
         filesz 0x00005660 memsz 0x00005660 flags r-x
    LOAD off    0x00005660 vaddr 0x00006660 paddr 0x00006660 align 2**12
         filesz 0x0000091c memsz 0x00000958 flags rw-
 DYNAMIC off    0x00005e28 vaddr 0x00006e28 paddr 0x00006e28 align 2**2
         filesz 0x000000d8 memsz 0x000000d8 flags rw-

Dynamic Section:
  NEEDED      libc.so.0.3
  SONAME      libgcc_s.so.1
  INIT        0xef4
  FINI        0x542c
  HASH        0x94
  STRTAB      0x900
  SYMTAB      0x320
  STRSZ       0x3ec
  SYMENT      0x10
  PLTGOT      0x6f10
  PLTRELSZ    0x98
  PLTREL      0x11
  JMPREL      0xe5c
  REL         0xe24
  RELSZ       0x38
  RELENT      0x8
  VERDEF      0xda8
  VERDEFNUM   0x3
  VERNEED     0xe04
  VERNEEDNUM  0x1
  VERSYM      0xcec

Version definitions:
1 0x01 0x04bd5c11 libgcc_s.so.1
2 0x00 0x0d696910 GLIBC_2.0
3 0x00 0x0b792650 GCC_3.0
        GLIBC_2.0 

Version References:
  required from libc.so.0.3:
    0x09691a75 0x00 04 GLIBC_2.2.5

> > Please let me know as soon as you can whether I can proceed with
> > this, or need to do more tests, or what.

> I want to change the errno definition, that is de-inline it, to
> avoid programs using the __hurd_sigthread_* et al symbols.  In the
> glibc-2.3 ABI, I think these will go away.

> So you'll have to recompile everything again (sorry).  

Will I see this change in "hurd" or in "glibc"?  (So I know where to
look before I start recompiling)

> But this is a compatible change, i.e. the binaries you have now will
> continue to work.  We just want to make sure not to get an installed
> base of binaries using those symbols.

Question - Do you have a plan for what makes it a "0.3" ABI vs. a
"1.0" ABI?  If this should be a fairly stable and long term change, it
might be nice to have at least something of ours at a 1.0 stage.

I just want to ask before I recompile everything. =)

-- 
I gotta ding ding dang a dang a long ding dong.