From: Lukasz Majewski <lukma@denx.de>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: libc-help@sourceware.org, Joseph Myers <joseph@codesourcery.com>
Subject: Re: Question regarding __clock_gettime symbol visibility across glibc build
Date: Tue, 17 Mar 2020 09:51:50 +0100 [thread overview]
Message-ID: <20200317095150.1777ddc4@jawa> (raw)
In-Reply-To: <87fte7fkhc.fsf@mid.deneb.enyo.de>
[-- Attachment #1: Type: text/plain, Size: 3133 bytes --]
Hi Florian,
> * Lukasz Majewski:
>
> > However, I've checked how it looks on the installed glibc:
> > root@y2038arm:/opt# nm /opt/lib/libc.so.6 | grep clock_gettime
> >
> > 000702bc t __GI___clock_gettime
> > 00070264 t __GI___clock_gettime64
> > 000702bc T __clock_gettime
> > 00070264 T __clock_gettime64
> > 000702bc t __clock_gettime_2
> > 000702bc T clock_gettime@@GLIBC_2.17
> > 000702bc T clock_gettime@GLIBC_2.4
> >
> > In the installed glibc the __clock_gettime64 is an external symbol.
> >
>
> All exported glibc symbols are versioned. Chances are that nm does
> not look at the dynamic symbol table at all, so its output is
> misleading. I usually use eu-readelf --symbols=.dynsym instead.
It seems like nm is correct here.
The output of installed libc.so:
root@y2038arm:/opt# readelf --symbols /opt/lib/libc.so.6 | grep clock_gettime
846: 000702bd 64 FUNC GLOBAL DEFAULT 12 __clock_gettime@@GLIBC_PRIVATE
1515: 00070265 88 FUNC GLOBAL DEFAULT 12 __clock_gettime64@@GLIBC_PRIVATE
1751: 000702bd 64 FUNC GLOBAL DEFAULT 12 clock_gettime@GLIBC_2.4
1755: 000702bd 64 FUNC GLOBAL DEFAULT 12 clock_gettime@@GLIBC_2.17
3830: 00000000 0 FILE LOCAL DEFAULT ABS clock_gettime.c
10342: 000702bd 64 FUNC LOCAL DEFAULT 12 __clock_gettime_2
10624: 00070265 88 FUNC LOCAL DEFAULT 12 __GI___clock_gettime64
11251: 000702bd 64 FUNC LOCAL DEFAULT 12 __GI___clock_gettime
11893: 000702bd 64 FUNC GLOBAL DEFAULT 12 __clock_gettime
11966: 000702bd 64 FUNC GLOBAL DEFAULT 12 clock_gettime@GLIBC_2.4
12166: 00070265 88 FUNC GLOBAL DEFAULT 12 __clock_gettime64
13749: 000702bd 64 FUNC GLOBAL DEFAULT 12 clock_gettime@@GLIBC_2.17
The one when libmemusage.so is linked:
readelf --symbols glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/libc.so | grep clock_gettime
834: 0009a8e0 100 FUNC GLOBAL DEFAULT 11 __clock_gettime@@GLIBC_PRIVATE
1729: 0009a8e0 100 FUNC GLOBAL DEFAULT 11 clock_gettime@GLIBC_2.4
1733: 0009a8e0 100 FUNC GLOBAL DEFAULT 11 clock_gettime@@GLIBC_2.17
3658: 00000000 0 FILE LOCAL DEFAULT ABS clock_gettime.c
9435: 0009a774 364 FUNC LOCAL DEFAULT 11 __clock_gettime64
10187: 0009a8e0 100 FUNC LOCAL DEFAULT 11 __clock_gettime_2
10478: 0009a774 364 FUNC LOCAL DEFAULT 11 __GI___clock_gettime64
11124: 0009a8e0 100 FUNC LOCAL DEFAULT 11 __GI___clock_gettime
11729: 0009a8e0 100 FUNC GLOBAL DEFAULT 11 __clock_gettime
11802: 0009a8e0 100 FUNC GLOBAL DEFAULT 11 clock_gettime@GLIBC_2.4
13564: 0009a8e0 100 FUNC GLOBAL DEFAULT 11 clock_gettime@@GLIBC_2.17
The results are the same -> __clock_gettime64 is GLOBAL on installed glibc
and LOCAL when linking libmemusage.so.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-03-17 8:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-17 7:47 Lukasz Majewski
2020-03-17 8:34 ` Florian Weimer
2020-03-17 8:51 ` Lukasz Majewski [this message]
2020-03-21 7:00 ` Lukasz Majewski
2020-03-23 21:57 ` Joseph Myers
2020-03-23 22:14 ` Lukasz Majewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200317095150.1777ddc4@jawa \
--to=lukma@denx.de \
--cc=fw@deneb.enyo.de \
--cc=joseph@codesourcery.com \
--cc=libc-help@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).