From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12575 invoked by alias); 31 Jan 2011 09:00:24 -0000 Received: (qmail 12523 invoked by uid 22791); 31 Jan 2011 09:00:23 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 31 Jan 2011 09:00:18 +0000 Received: by wwi17 with SMTP id 17so5210568wwi.12 for ; Mon, 31 Jan 2011 01:00:16 -0800 (PST) Received: by 10.216.174.65 with SMTP id w43mr10015302wel.95.1296464416056; Mon, 31 Jan 2011 01:00:16 -0800 (PST) Received: from [192.168.2.99] (cpc2-cmbg8-0-0-cust61.5-4.cable.virginmedia.com [82.6.108.62]) by mx.google.com with ESMTPS id n18sm10646800wee.16.2011.01.31.01.00.13 (version=SSLv3 cipher=RC4-MD5); Mon, 31 Jan 2011 01:00:14 -0800 (PST) Message-ID: <4D468025.1020105@gmail.com> Date: Mon, 31 Jan 2011 09:00:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ali hagigat CC: Ian Lance Taylor , binutils@sourceware.org Subject: Re: why ld return with error? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-01/txt/msg00397.txt.bz2 On 31/01/2011 08:28, ali hagigat wrote: > Thank you for the reply. I think that GCC compiler collection has the > definitions and C code of some standard libraries. It means that the > code of printf exists inside the code of gcc and gcc does not need to > go to /usr/bin on hard disk to find libc.a and then find the defintion > and the body of printf. > Is that right? or I am mistaken? > If I am mistaken what will be the meaning of -fno-builtin then? I > think the code of built-in functions exist inside the code segment of > gcc when it is invoked. GCC's built-ins are an internal mechanism by which the compiler can "know" enough about what goes on inside a function such as printf to be able to optimise it - in some but not all cases - but ultimately they rely on the underlying functionality of the system's C library. They're kind of synthetic inline wrappers around the real functions, that in some cases can be simplified during expansion. They don't actually have the functionality that the C library supplies; you could picture the builtin printf as being something roughly like this: int builtin_printf (const char *fmt, ...) __attribute__ ((__always_inline__)) { if (__builtin_constant_p (fmt) && (strcmp (fmt, "%s") == 0 || strchr (fmt, "%") == NULL)) { if (strcmp (fmt, "%s") == 0) { str = GET_FIRST_VARARG(); } else { str = fmt; } /* If the string was "", printf does nothing. */ if (str[0] == '\0') return 0; /* If the string has length of 1, call putchar. */ if (str[1] == '\0) { builtin_putchar (fmt[0]); return 1; } /* If the string was "string\n", call puts("string"). */ . . . /* Other optimisations etc. */ . . . } /* Can't optimise it if we don't know the format string at compile time, so pass it through to the . */ return __builtin_apply (printf, __builtin_apply_args(), GET_VARARGS_SIZE()); } When the compiler comes to inline this into a function that is calling printf, it will end up either optimising the whole thing away into a call to the C lib's underlying printf function, or translate it into a call with modified args to builtin_putchar or builtin_puts, which each may also make further transformations or just optimise away into a libcall likewise. So in the end all the actual functionality still has to come from the C library anyway. cheers, DaveK