From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5074 invoked by alias); 5 Jul 2013 08:04:02 -0000 Mailing-List: contact prelink-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: prelink-owner@sourceware.org Received: (qmail 5025 invoked by uid 89); 5 Jul 2013 08:04:02 -0000 X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,SPF_PASS,TW_LR autolearn=ham version=3.3.1 X-Spam-User: qpsmtpd, 2 recipients Received: from mail-pd0-f175.google.com (HELO mail-pd0-f175.google.com) (209.85.192.175) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 05 Jul 2013 08:03:45 +0000 Received: by mail-pd0-f175.google.com with SMTP id 4so1780186pdd.34 for ; Fri, 05 Jul 2013 01:03:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.218.199 with SMTP id pi7mr8741736pbc.19.1373011424318; Fri, 05 Jul 2013 01:03:44 -0700 (PDT) Received: by 10.70.75.68 with HTTP; Fri, 5 Jul 2013 01:03:44 -0700 (PDT) In-Reply-To: References: Date: Fri, 05 Jul 2013 08:04:00 -0000 Message-ID: Subject: Re: Prelink fails on ARM when use API CLOCK_GETTIME From: naveen yadav To: Ian Lance Taylor , prelink@sourceware.org, jacob@redhat.com, binutils Development , gcc-help@gnu.org, gcc-help@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2013-q3/txt/msg00001.txt.bz2 one more is there any gcc option i can supress this funcationality. Thanks On Thu, Jul 4, 2013 at 10:44 AM, naveen yadav wrote: > Dear All, > > > I was trying to prelink and run the below mentioned test case, cross > compiled with arm toolchain (gcc-4.7.3). > > #include > > #include > > #include > > #include > > #include > > > > int main() > > { > > int rst; > > struct timespec to; > > > > rst = clock_gettime(CLOCK_MONOTONIC, &to); > > if(rst != 0) > > { > > printf("Got some error and error code may be %d > %d\n",rst,errno); > > } > > else > > { > > printf("clock_gettime returned=%d", rst); > > printf("rst=%d to.to_sec=%d", rst, to.tv_sec); > > > > } > > } > > > > Compiled the above test case as: > $arm-linux-gnueabi-gcc -o time_with_rt time.c -lrt > > > On linking it with rt library, and after prelinking it on host (x86 > machine), running on the ARM target, it gives output as: > $ ./time_with_rt > > 624: number of relocations: 0 > > 624: number of relocations from cache: 29 > > 624: number of relative relocations: 0 > > Got some error and error code may be 1091638508 0 > > 624: > > 624: runtime linker statistics: > > 624: final number of relocations: 0 > > 624: final number of relocations from cache: 29 > > > > I have a query: > > Why the return value in 'rst' variable is some large non-zero number? > The function clock_gettime() ideally returns either 0 or -1, if I am > not wrong? Why and How this large value is returned? > > > Also, my another observation regarding the same test case is as shown below. > > $ arm-linux-gnueabi-readelf -a lib/libc.so.6 | grep clock_gettime > > 783: 411114ec 108 FUNC GLOBAL DEFAULT 11 __clock_gettime@@GLIBC_PRIVATE > 1628: 411114ec 108 FUNC GLOBAL DEFAULT 11 clock_gettime@@GLIBC_2.17 > 10080: 00000000 0 FILE LOCAL DEFAULT ABS clock_gettime.c > 15736: 411114ec 108 FUNC GLOBAL DEFAULT 11 __clock_gettime > 15890: 411114ec 108 FUNC GLOBAL DEFAULT 11 clock_gettime > > > $ arm-linux-gnueabi-readelf -a lib/librt.so.1 | grep clock_gettime > > 411ce124 00002b15 R_ARM_GLOB_DAT 00000000 __clock_gettime > 43: 00000000 0 FUNC GLOBAL DEFAULT UND > __clock_gettime@GLIBC_PRIVATE (5) > 84: 411c4b0c 28 IFUNC GLOBAL DEFAULT 12 clock_gettime@@GLIBC_2.4 > 497: 411c4b0c 28 IFUNC GLOBAL DEFAULT 12 clock_gettime > 547: 00000000 0 FUNC GLOBAL DEFAULT UND __clock_gettime@@GLIBC_PR > > > > > While looking for symbol, clock_gettime in the ELF of libc and lrt, I > found that in librt.so.1, its function attribute is IFUNC. I am not > clear how the symbols are resolved with function attribute IFUNC. And, > do the latest prelink support IFUNC function types yet? It would be > great if you can explain the concept of how this type of symbols are > handled differently. > > Thanks