From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 13:16:05 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 637AE16A402; Tue, 13 Mar 2007 13:16:05 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id E1FB313C483; Tue, 13 Mar 2007 13:16:04 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.11.22] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1HR6qz1iWi-00070a; Tue, 13 Mar 2007 14:15:56 +0100 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Tue, 13 Mar 2007 14:15:38 +0100 User-Agent: KMail/1.9.5 References: <20070313121106.GA96293@nagual.pp.ru> <20070313123717.GU58523@codelabs.ru> In-Reply-To: <20070313123717.GU58523@codelabs.ru> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2353553.gtTboZbrzb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200703131415.45709.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/MttCl7XZRxN5JIM4PTQ/cZzhS+X/T5Q47ipW 8JcVc3X75YQwLQT/lkvMjv3Tq8mDf+RyS6ksvWn+0SWtgP/zgk PVErV7ND0tjsvBkonWsEg== Cc: Subject: Re: Bad gcc -O optimization cause core dump. What to do? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 13:16:05 -0000 --nextPart2353553.gtTboZbrzb Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 13 March 2007 13:37, Eygene Ryabinkin wrote: > Andrey, good day. > > > It calls "puts(NULL)" with core dump. > > It means "printf("%s\n", NULL)" is overoptimized. > > BTW, things like "printf("1%s\n", NULL)" are not overoptimized. > > Yes, it is in the gcc/builtins.c::expand_builtin_printf(). Currently > it only handles "%s" and "%c". > > > Any ideas? Is it right or needs to be fixed? > > It is definitely not right, since it produces the bad code. > And there are no compilation-time checks that can say for > sure will the argument for the "%s" be NULL: This is simply a programming error. Just because the function is called=20 printf doesn't make it right. It's nice that the libc's printf does all=20 these neat tricks, but it's also expensive (See the link I posted=20 earlier). According to the printf(3) manpage: s The char * argument is expected to be a pointer to an array of character type (pointer to a string). Characters from the array are written up to (but not including) a terminating NUL charac- ter; if a precision is specified, no more than the number speci- fied are written. If a precision is given, no null character need be present; if the precision is not specified, or is greater than the size of the array, the array must contain a terminating NUL character. And I fail to see how "NULL" is a valid pointer to an array of character=20 type. This is C after all. > ----- > $ cat 1.c > #include > > int main(void) > { > void *ptr =3D NULL; > func(ptr); > } > > int func(void *ptr) > { > printf("%s\n", ptr); > } > > :: rea@codelabs : 15:31:43 : ~/xlam > > $ cat 1.s > .file "1.c" > .text > .p2align 2,,3 > .globl main > .type main, @function > main: > pushl %ebp > movl %esp, %ebp > subl $8, %esp > andl $-16, %esp > subl $28, %esp > pushl $0 > call func > leave > ret > .size main, .-main > .p2align 2,,3 > .globl func > .type func, @function > func: > pushl %ebp > movl %esp, %ebp > subl $20, %esp > pushl 8(%ebp) > call puts > leave > ret > .size func, .-func > ----- > The possible way to proceed with this optimization is to have the > 'puts', but to enable runtime check for the NULL value. > > I see the following definition for the fn_puts in builtins.def: > ----- > DEF_EXT_LIB_BUILTIN (BUILT_IN_PUTS_UNLOCKED, "puts_unlocked", > BT_FN_INT_CONST_STRING, ATTR_NOTHROW_NONNULL_1) ----- > The ATTR_NOTHROW_NONNULL_1 makes me think that not all is lost and > something can be done with the NULL pointer. I am not very familiar > with gcc internals, but I will try to see if something can be changed. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2353553.gtTboZbrzb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBF9qQBXyyEoT62BG0RAqONAJwOCMP+nq0RW+AzM/dr2dvZltMc0wCbBIpF eqzpU0iXc9xBu6h9qPJyuT8= =vBHA -----END PGP SIGNATURE----- --nextPart2353553.gtTboZbrzb--