Re: problems with ctype...

Re: problems with ctype...

[Roland McGrath]

> Nope, I mean -Wr. If libc.so doesn't have any R_386_GLOB_DAT __ctype_b

Ah, I see the problem now.  Always forgetting about those pesky copy relocs.

I inserted compat_symbol (i.e. .symver) decls in lc-ctype.c where the
variables are set, and that gets those relocs bound early to the versioned
name and thus proper GLOB_DAT relocs in the shared object.

This exposed a trivial ld.so bug in handling relocs referring to
non-default versioned symbols defined in the same object, which I fixed.

I think this puts this problem to rest.  The only thing I don't know is if
older binutils versions have any problem producing the right output with
this usage.  I would tend to doubt off hand that it's a problem with the
new straightforward usage of the symbols by their versioned names.

Re: problems with ctype...

[H. J. Lu]

On Mon, Sep 16, 2002 at 09:54:25PM -0700, Roland McGrath wrote:
> > They are real bugs exposed by glibc 2.3 and gcc 3.2. Please ask users
> > to upgrade binutils.
> 
> I think that is fine, we just need to be able to make it easy for users for
> be doing the right thing.  i.e. a configure check that will really prevent

You can take a look at the testcases I added to binutils. They are
vers23, vers22 and vers21 in ld/testsuite/ld-elfvers.

> people from attempting to use the losing tools.  Hopefully we can see a
> future GNU binutils release relatively soon so that we can have a clear,
> canonical, and official GNU, best version to refer to.

I don't think you can count on that unless they make a release for
every Linux bug fixed, which is what I have been doing with my Linux
binutils.


H.J.

Re: problems with ctype...

[Roland McGrath]

> They are real bugs exposed by glibc 2.3 and gcc 3.2. Please ask users
> to upgrade binutils.

I think that is fine, we just need to be able to make it easy for users for
be doing the right thing.  i.e. a configure check that will really prevent
people from attempting to use the losing tools.  Hopefully we can see a
future GNU binutils release relatively soon so that we can have a clear,
canonical, and official GNU, best version to refer to.

Re: problems with ctype...

[H. J. Lu]

On Mon, Sep 16, 2002 at 09:00:59AM +0200, Andreas Jaeger wrote:
> Roland McGrath <roland@redhat.com> writes:
> 
> >> I just tried it with newer binutils (2.12.90.0.15 20020717) and that
> >> worked fine.  We might need to document the minimal supported binutils
> >> version.
> >
> > Certainly so.  If there is some simple change that makes it work with more
> > binutils versions, I would be happy with that too.
> 
> Unfortunatly I haven't figured out such a way yet :-(

They are real bugs exposed by glibc 2.3 and gcc 3.2. Please ask users
to upgrade binutils.



H.J.

Re: problems with ctype...

[H. J. Lu]

On Mon, Sep 16, 2002 at 09:01:38AM +0200, Jakub Jelinek wrote:
> 
> Ours is binutils 2.13.90.0.2. Well, we need to find out the oldest
> binutils which worked ok and also write a binutils testcase whcih will
> ensure this will work right from now on.

I added at least one testcase to binutils for each symbol versioning
bug I fixed.  You can take a look at them.


H.J.

Re: problems with ctype...

[H. J. Lu]

On Mon, Sep 16, 2002 at 08:52:35AM +0200, Andreas Jaeger wrote:
> Roland McGrath <roland@redhat.com> writes:
> 
> > It certainly works fine for me, but I am not using the same tools.
> > I am using GCC 3.2 with RH modifications and binutils is also a RH version.
> 
> I just tried it with newer binutils (2.12.90.0.15 20020717) and that
> worked fine.  We might need to document the minimal supported binutils
> version.

From release.binutils-2.13.90.0.4:

----
Changes from binutils 2.13.90.0.3:

1. Update from binutils 2002 0814.
2. Fix symbol versioning bugs for gcc 3.2.
3. Fix mips gas.

Changes from binutils 2.13.90.0.2:

1. Update from binutils 2002 0809.
2. Fix a mips gas compatibility bug.
3. Fix an x86 TLS bfd bug.
4. Fix an x86 PIC gas bug.
5. Improve symbol versioning support.

Changes from binutils 2.12.90.0.15:

1. Update from binutils 2002 0802.
2. Initial support for mips n32 ABI.
3. Fix some x86 TLS bugs.

Changes from binutils 2.12.90.0.14:

1. Update from binutils 2002 0717.
2. Fix an ia64 assembler bug.
3. Fix a symbol versioning bug.
4. You have to upgrade to modutils 2.4.19 or apply the modutils patch
enclosed here in order to support System.map generated by the new nm.
---

If you have to document the minimal supported binutils version, please
use 2.13.90.0.4 since it has another symbol versioning fix.



H.J.

Re: problems with ctype...

[Roland McGrath]

> Actually, looking at it again, what is in CVS doesn't work at all.

Works just fine for me.

> Just readelf -Wr libc.so | grep __ctype to find out.

You mean -Ws, no doubt.  Here are just the __ctype_b matches in mine:

  1721: 00021f98   114 FUNC    GLOBAL DEFAULT   11 __ctype_b_loc@@GLIBC_2.3
  2013: 00112a34     4 OBJECT  GLOBAL DEFAULT   16 __ctype_b@GLIBC_2.0
  3595: 00112a34     4 OBJECT  LOCAL  DEFAULT   16 __ctype_b
  6681: 00021f98   114 FUNC    GLOBAL DEFAULT   11 __ctype_b_loc
  6973: 00112a34     4 OBJECT  GLOBAL DEFAULT   16 __ctype_b@GLIBC_2.0

> If it was supposed to work, it would have to have __ctype_b@GLIBC_2.0 
> (or __ctype_b@@GLIBC_2.0) etc. dynamic relocs.

???  Must be too early in the morning, else it's too late for me.  There
are no relocs referring to these symbols because the references resolve
internally.  There are dynamic symbol table entries as there should be.

Re: problems with ctype...

[Jakub Jelinek]

On Mon, Sep 16, 2002 at 09:03:54AM +0200, Andreas Jaeger wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
> 
> > On Mon, Sep 16, 2002 at 08:52:35AM +0200, Andreas Jaeger wrote:
> >> Roland McGrath <roland@redhat.com> writes:
> >> 
> >> > It certainly works fine for me, but I am not using the same tools.
> >> > I am using GCC 3.2 with RH modifications and binutils is also a RH version.
> >> 
> >> I just tried it with newer binutils (2.12.90.0.15 20020717) and that
> >> worked fine.  We might need to document the minimal supported binutils
> >> version.
> >
> > Ours is binutils 2.13.90.0.2. Well, we need to find out the oldest
> > binutils which worked ok and also write a binutils testcase whcih will
> > ensure this will work right from now on.
> 
> I can easily test this with my old and broken binutils (2.12.90.0.4
> 20020408) but so far I didn't fully grab the problem and how a
> testcase might look.
> 
> > I think it is an useful feature to be able to access a compat-only variable
> > (and getting to it through aliases doesn't work because of COPY relocs).

Actually, looking at it again, what is in CVS doesn't work at all.
Just readelf -Wr libc.so | grep __ctype to find out.
If it was supposed to work, it would have to have __ctype_b@GLIBC_2.0 
(or __ctype_b@@GLIBC_2.0) etc. dynamic relocs.
I'm afraid we're back where we used to be, ie. either have to make these
symbols @@GLIBC_2.0 etc. (while leaving the headers as is, ie. not declaring
nor using them), or have to apply post-link hackery using libelf, or
come up with a new binutils solution and require binutils 2.14+.

	Jakub

Re: problems with ctype...

[Andreas Jaeger]

Jakub Jelinek <jakub@redhat.com> writes:

> On Mon, Sep 16, 2002 at 08:52:35AM +0200, Andreas Jaeger wrote:
>> Roland McGrath <roland@redhat.com> writes:
>> 
>> > It certainly works fine for me, but I am not using the same tools.
>> > I am using GCC 3.2 with RH modifications and binutils is also a RH version.
>> 
>> I just tried it with newer binutils (2.12.90.0.15 20020717) and that
>> worked fine.  We might need to document the minimal supported binutils
>> version.
>
> Ours is binutils 2.13.90.0.2. Well, we need to find out the oldest
> binutils which worked ok and also write a binutils testcase whcih will
> ensure this will work right from now on.

I can easily test this with my old and broken binutils (2.12.90.0.4
20020408) but so far I didn't fully grab the problem and how a
testcase might look.

> I think it is an useful feature to be able to access a compat-only variable
> (and getting to it through aliases doesn't work because of COPY relocs).

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: problems with ctype...

[Jakub Jelinek]

On Mon, Sep 16, 2002 at 08:52:35AM +0200, Andreas Jaeger wrote:
> Roland McGrath <roland@redhat.com> writes:
> 
> > It certainly works fine for me, but I am not using the same tools.
> > I am using GCC 3.2 with RH modifications and binutils is also a RH version.
> 
> I just tried it with newer binutils (2.12.90.0.15 20020717) and that
> worked fine.  We might need to document the minimal supported binutils
> version.

Ours is binutils 2.13.90.0.2. Well, we need to find out the oldest
binutils which worked ok and also write a binutils testcase whcih will
ensure this will work right from now on.
I think it is an useful feature to be able to access a compat-only variable
(and getting to it through aliases doesn't work because of COPY relocs).

	Jakub

Re: problems with ctype...

[Andreas Jaeger]

Roland McGrath <roland@redhat.com> writes:

>> I just tried it with newer binutils (2.12.90.0.15 20020717) and that
>> worked fine.  We might need to document the minimal supported binutils
>> version.
>
> Certainly so.  If there is some simple change that makes it work with more
> binutils versions, I would be happy with that too.

Unfortunatly I haven't figured out such a way yet :-(

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: problems with ctype...

[Roland McGrath]

> I just tried it with newer binutils (2.12.90.0.15 20020717) and that
> worked fine.  We might need to document the minimal supported binutils
> version.

Certainly so.  If there is some simple change that makes it work with more
binutils versions, I would be happy with that too.

Re: problems with ctype...

[Andreas Jaeger]

Roland McGrath <roland@redhat.com> writes:

> It certainly works fine for me, but I am not using the same tools.
> I am using GCC 3.2 with RH modifications and binutils is also a RH version.

I just tried it with newer binutils (2.12.90.0.15 20020717) and that
worked fine.  We might need to document the minimal supported binutils
version.

>
> In my build the libc.so.6 symbol table contains (this is readelf -s output):
>
>    988: 00112a40     4 OBJECT  GLOBAL DEFAULT   16 __ctype_toupper@GLIBC_2.0
>   3865: 00112a40     4 OBJECT  LOCAL  DEFAULT   16 __ctype_toupper

gromit:/builds/glibc/gcc-3.3:[2]$ readelf -s libc.so.6 |grep ctype_toupper
[From dynsym:]
   696: 0010fb2c     4 OBJECT  GLOBAL DEFAULT   16 __ctype_toupper@@GLIBC_2.0
   989: 0010fb2c     4 OBJECT  GLOBAL DEFAULT   16 __ctype_toupper@GLIBC_2.0
  1923: 00022692   114 FUNC    GLOBAL DEFAULT   11 __ctype_toupper_loc@@GLIBC_2.3
[From .symtab]
  5647: 0010fb2c     4 OBJECT  GLOBAL DEFAULT   16 __ctype_toupper
  5940: 0010fb2c     4 OBJECT  GLOBAL DEFAULT   16 __ctype_toupper@GLIBC_2.0
  6874: 00022692   114 FUNC    GLOBAL DEFAULT   11 __ctype_toupper_loc

> and the dynamic symbol table contains:
>
>   5948: 00112a40     4 OBJECT  GLOBAL DEFAULT   16 __ctype_toupper@GLIBC_2.0
>
> In libc_pic.a, lc-ctype.os has: 
>
>     25: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __ctype_toupper
>
> and ctype/ctype-info.os has:
>
>     32: 0000000c     4 OBJECT  GLOBAL DEFAULT   10 __ctype_toupper
>     39: 0000000c     4 OBJECT  GLOBAL DEFAULT   10 __ctype_toupper@GLIBC_2.0

These  looks the same for me.
>
> Those are the only __ctype_toupper references.  How does this compare with
> the symbols in your build?
>
> Perhaps the ld behavior is different. I don't know what the *IND* magic in
> the linker error message is.  I presume that your libc.so.6 symbol tables
> must look different from mine, or the error doesn't make sense.

> I'm not sure if it's supposed to be the case that the references in
> lc-ctype.os uses the versioned name when it's being linked -shared with the
> object that defines the non-default versioned name.  But I think not, since
> there is also a plain global __ctype_toupper defined in ctype-info.os.  I
> could understand the multiple definition error more if it came up doing the
> ld -shared instead.  


Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: problems with ctype...

[Roland McGrath]

It certainly works fine for me, but I am not using the same tools.
I am using GCC 3.2 with RH modifications and binutils is also a RH version.

In my build the libc.so.6 symbol table contains (this is readelf -s output):

   988: 00112a40     4 OBJECT  GLOBAL DEFAULT   16 __ctype_toupper@GLIBC_2.0
  3865: 00112a40     4 OBJECT  LOCAL  DEFAULT   16 __ctype_toupper

and the dynamic symbol table contains:

  5948: 00112a40     4 OBJECT  GLOBAL DEFAULT   16 __ctype_toupper@GLIBC_2.0

In libc_pic.a, lc-ctype.os has: 

    25: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __ctype_toupper

and ctype/ctype-info.os has:

    32: 0000000c     4 OBJECT  GLOBAL DEFAULT   10 __ctype_toupper
    39: 0000000c     4 OBJECT  GLOBAL DEFAULT   10 __ctype_toupper@GLIBC_2.0

Those are the only __ctype_toupper references.  How does this compare with
the symbols in your build?

Perhaps the ld behavior is different. I don't know what the *IND* magic in
the linker error message is.  I presume that your libc.so.6 symbol tables
must look different from mine, or the error doesn't make sense.

I'm not sure if it's supposed to be the case that the references in
lc-ctype.os uses the versioned name when it's being linked -shared with the
object that defines the non-default versioned name.  But I think not, since
there is also a plain global __ctype_toupper defined in ctype-info.os.  I
could understand the multiple definition error more if it came up doing the
ld -shared instead.  

problems with ctype...

[Andreas Jaeger]

Roland,

This patch looks broken:
2002-09-05  Roland McGrath  <roland@redhat.com>

	* ctype/ctype-info.c: Renamed __ctype_old_* symbols to __ctype_*.
	* locale/lc-ctype.c (_nl_postload_ctype): Likewise.

With current CVS I get:

/opt/gcc/3.3-devel/bin/gcc -nostdlib -nostartfiles -o /builds/glibc/gcc-3.3/iconv/iconvconfig  -Wl,-dynamic-linker=/usr/src/test/glibc-2.3/lib/ld-linux.so.2   -Wl,-z,combreloc /builds/glibc/gcc-3.3/csu/crt1.o /builds/glibc/gcc-3.3/csu/crti.o `/opt/gcc/3.3-devel/bin/gcc --print-file-name=crtbegin.o` /builds/glibc/gcc-3.3/iconv/iconvconfig.o /builds/glibc/gcc-3.3/iconv/strtab.o /builds/glibc/gcc-3.3/iconv/xmalloc.o  -Wl,-rpath-link=/builds/glibc/gcc-3.3:/builds/glibc/gcc-3.3/math:/builds/glibc/gcc-3.3/elf:/builds/glibc/gcc-3.3/dlfcn:/builds/glibc/gcc-3.3/nss:/builds/glibc/gcc-3.3/nis:/builds/glibc/gcc-3.3/rt:/builds/glibc/gcc-3.3/resolv:/builds/glibc/gcc-3.3/crypt:/builds/glibc/gcc-3.3/linuxthreads /builds/glibc/gcc-3.3/libc.so.6 /builds/glibc/gcc-3.3/libc_nonshared.a -lgcc `/opt/gcc/3.3-devel/bin/gcc --print-file-name=crtend.o` /builds/glibc/gcc-3.3/csu/crtn.o
/builds/glibc/gcc-3.3/libc.so.6(.data+0xb2c): multiple definition of `__ctype_toupper@GLIBC_2.0'
/builds/glibc/gcc-3.3/libc.so.6(*IND*+0x0): multiple definition of `__ctype32_toupper@GLIBC_2.2'
/builds/glibc/gcc-3.3/libc.so.6(.data+0xb34): first defined here
/builds/glibc/gcc-3.3/libc.so.6(.data+0xb30): multiple definition of `__ctype32_tolower@GLIBC_2.2'
/builds/glibc/gcc-3.3/libc.so.6(.data+0xb20): multiple definition of `__ctype_b@GLIBC_2.0'
/builds/glibc/gcc-3.3/libc.so.6(*IND*+0x0): multiple definition of `__ctype_tolower@GLIBC_2.0'
/builds/glibc/gcc-3.3/libc.so.6(.data+0xb28): first defined here
/builds/glibc/gcc-3.3/libc.so.6(.data+0xb24): multiple definition of `__ctype32_b@GLIBC_2.0'
collect2: ld returned 1 exit status

but reverting the ctype-info.c part I get no more duplicates but only:
/builds/glibc/gcc-3.3/libc.so.6: undefined reference to `__ctype32_b'
/builds/glibc/gcc-3.3/libc.so.6: undefined reference to `__ctype_b'
/builds/glibc/gcc-3.3/libc.so.6: undefined reference to `__ctype_toupper'
/builds/glibc/gcc-3.3/libc.so.6: undefined reference to `__ctype32_toupper'
/builds/glibc/gcc-3.3/libc.so.6: undefined reference to `__ctype32_tolower'
/builds/glibc/gcc-3.3/libc.so.6: undefined reference to `__ctype_tolower'

This is with GCC 3.3 CVS and binutils 2.12.90.0.4 20020408 on i686-linux-gnu.

Any ideas what's going wrong here?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj