From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 24 23:44:25 2005 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20B7C16A4CE for ; Thu, 24 Mar 2005 23:44:25 +0000 (GMT) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id B982643D2D for ; Thu, 24 Mar 2005 23:44:24 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 6C9FEF3F2B; Thu, 24 Mar 2005 15:44:24 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02642-08; Thu, 24 Mar 2005 15:44:23 -0800 (PST) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 38132F3EE8; Thu, 24 Mar 2005 15:44:23 -0800 (PST) From: Sean McNeil To: Jung-uk Kim In-Reply-To: <200503241822.00480.jkim@niksun.com> References: <20050324214956.GA99087@dragon.NUXI.org> <1111702231.2655.6.camel@server.mcneil.com> <200503241822.00480.jkim@niksun.com> Content-Type: text/plain Date: Thu, 24 Mar 2005 15:44:22 -0800 Message-Id: <1111707862.37802.14.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-amd64@freebsd.org Subject: Re: undefined reference to `memset' X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2005 23:44:25 -0000 On Thu, 2005-03-24 at 18:22 -0500, Jung-uk Kim wrote: > On Thursday 24 March 2005 05:10 pm, Sean McNeil wrote: > > On Thu, 2005-03-24 at 13:49 -0800, David O'Brien wrote: > > > Please don't top-post -- it destroys context. [Format recovered] > > > > > > On Thu, Mar 24, 2005 at 12:46:41PM -0800, Vinod Kashyap wrote: > > > > > On Thu, Mar 24, 2005 at 06:05:17PM +1100, Peter Jeremy wrote: > > > > > > On Wed, 2005-Mar-23 13:48:04 -0800, Vinod Kashyap wrote: > > > > > > >If any kernel module has the following, or a similar line > > > > > > > in it: ----- > > > > > > >char x[100] = {0}; > > > > > > >----- > > > > > > >building of the GENERIC kernel on FreeBSD 5 -STABLE for > > > > > > > amd64 as of 03/19/05, fails with the following message at > > > > > > > the > > > > > > > > > > time of linking: > > > > > > >"undefined reference to `memset'". > > > > > > > > > > > > > >The same problem is not seen on i386. > > > > > > > > > > > > > >The problem goes away if the above line is changed to: > > > > > > >----- > > > > > > >char x[100]; > > > > > > >memset(x, 0, 100); > > > > > > >----- > > > > > > > > > > > > Can you post a complete (compilable) example please. > > > > > > > > > > Vinod can you please post a complete compilable example? > > > > > It is impossible to get anything done about your issue > > > > > without stand alone test code. > > > > > > > > Ok, make sure you have 'device twa' in your kernel > > > > configuration file, and apply these patches to > > > > /sys/dev/twa/twa.c. > > > > This patch causes the problem: > > > > > > "stand alone" means a single foo.c file that shows the problem > > > you want fixed. > > > I cannot submit a GCC bug report with a tarball of the entire > > > FreeBSD kernel. > > > > I've taken the liberty to write up an example here. Not sure if > > this is a bug or not: > > > > cc -O -pipe -c -fno-builtin -ffreestanding memset_bug.c > > > > Take a look at what is generated: > > > > objdump --disassemble memset_bug.o > > > > You'll see that instead of performing the inline code generation > > for memset, the compiler generates a call to memset in the case of > > the assignment of {0}. > > Have you tried -minline-all-stringops/-mno-inline-all-stringops? No, I was just trying to be helpful. Anyone can take the example I provided and do whatever they wish with it. I honestly do not have the time to fiddle with this much more than I already have. Sorry. The only concern I have with this is if gcc is doing the right thing here. Should memset be checked and expanded as an inline function when used within the initializer? IMHO, yes. All that being said, testing took less time that writing this email :) so..... with -mno-inline-all-stringops, no difference. with -minline-all-stringops, wow! memset inline function is gone and the code is way smaller: Disassembly of section .text: 0000000000000000 : 0: 48 81 ec 98 01 00 00 sub $0x198,%rsp 7: 48 89 e7 mov %rsp,%rdi a: fc cld b: b9 32 00 00 00 mov $0x32,%ecx 10: b8 00 00 00 00 mov $0x0,%eax 15: f3 48 ab repz stos %rax,%es:(%rdi) 18: 8b 34 24 mov (%rsp),%esi 1b: bf 00 00 00 00 mov $0x0,%edi 20: e8 00 00 00 00 callq 25 25: 48 81 c4 98 01 00 00 add $0x198,%rsp 2c: c3 retq as opposed to (with -O): Disassembly of section .text: 0000000000000000 : 0: 48 81 ec 98 01 00 00 sub $0x198,%rsp 7: 48 89 e7 mov %rsp,%rdi a: ba 90 01 00 00 mov $0x190,%edx f: be 00 00 00 00 mov $0x0,%esi 14: e8 27 00 00 00 callq 40 19: 8b 34 24 mov (%rsp),%esi 1c: bf 00 00 00 00 mov $0x0,%edi 21: b8 00 00 00 00 mov $0x0,%eax 26: e8 00 00 00 00 callq 2b 2b: 48 81 c4 98 01 00 00 add $0x198,%rsp 32: c3 retq 33: 66 data16 34: 66 data16 35: 66 data16 36: 90 nop 37: 66 data16 38: 66 data16 39: 90 nop 3a: 66 data16 3b: 66 data16 3c: 90 nop 3d: 66 data16 3e: 66 data16 3f: 90 nop 0000000000000040 : 40: 53 push %rbx 41: 48 89 fb mov %rdi,%rbx 44: 85 f6 test %esi,%esi 46: 75 0f jne 57 48: 48 89 d6 mov %rdx,%rsi 4b: b8 00 00 00 00 mov $0x0,%eax 50: e8 00 00 00 00 callq 55 55: eb 1b jmp 72 57: 48 89 f8 mov %rdi,%rax 5a: 48 ff ca dec %rdx 5d: 48 83 fa ff cmp $0xffffffffffffffff,%rdx 61: 74 0f je 72 63: 40 88 30 mov %sil,(%rax) 66: 48 ff c0 inc %rax 69: 48 ff ca dec %rdx 6c: 48 83 fa ff cmp $0xffffffffffffffff,%rdx 70: 75 f1 jne 63 72: 48 89 d8 mov %rbx,%rax 75: 5b pop %rbx 76: c3 retq Note, with -O (default for 5.x), a local version of memset is created, so all is well. As you can see with nm, 0000000000000000 T bug U bzero 0000000000000040 t memset U printf With -O2 (default for -current), there is no local version of memset. This could be considered a bug as well. nm shows 0000000000000000 T bug U memset U printf Cheers, Sean