From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 22:04:18 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C73C2D3C; Fri, 16 Nov 2012 22:04:18 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 88D5A8FC0C; Fri, 16 Nov 2012 22:04:18 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kp6so2297470pab.13 for ; Fri, 16 Nov 2012 14:04:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=gl0mnDsTONCdGDgTdmso0z18KRQaWeo176IfW6l3Bv8=; b=OvrQUCHlLkwi8Ozwa6P+ECC/fcWdALOJAs/T4fOugMDz2yuchKK4xm0MBLyoKZqgP+ MvI/DqA0FNBRRzgEeHvPV9G7aEPWl0xpqOrDnlflObImWEjn00xDSwA80OE9cr4v/Jaw ulm2DQl1I7pbp0UvZmP8xNCVoybCTXjw6SfmJBX0NuCcsCISqVwLxvPfCp7q1SSxFDMW na0sA20RgHOTh2pagIvqgn2hm8+6efuYg9VKD+kJLOzVGwXWq5iiGU4UwuL0C4h/w/0I t5g4JeP+RlXTlIBFDKMs/R0DTFPM4pzqtNZQ5jERYeb9tb6PwYIjL1CW+fnSovQV20gV UdmA== Received: by 10.68.234.36 with SMTP id ub4mr19240648pbc.68.1353103458286; Fri, 16 Nov 2012 14:04:18 -0800 (PST) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id c1sm1675670pav.23.2012.11.16.14.04.16 (version=SSLv3 cipher=OTHER); Fri, 16 Nov 2012 14:04:17 -0800 (PST) Message-ID: <50A6B85F.6090707@gmail.com> Date: Fri, 16 Nov 2012 14:04:15 -0800 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121114 Thunderbird/16.0.2 MIME-Version: 1.0 To: Roman Divacky Subject: Re: clang mangling some static struct names? References: <50A6A3BD.5000901@gmail.com> <20121116214919.GA41725@freebsd.org> In-Reply-To: <20121116214919.GA41725@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 22:04:19 -0000 On 11/16/12 13:49, Roman Divacky wrote: > Yes, it does that. iirc so that you can have things like > > void foo(int cond) { > if (cond) { > static int i = 7; > } else { > static int i = 8; > } > } > > working correctly. It's not appending the .n everywhere. And when it does, I don't see any potential collision that it prevented by doing so. Instead, it looks like the .n symbol corresponds to the nth element in the structure (so this is not name mangling in the true sense). I just don't see the point in doing things this way. It is only making things harder for debuggers. Regards, Navdeep > > I dont know why scsi_low_statics is there multiple times. > > On Fri, Nov 16, 2012 at 12:36:13PM -0800, Navdeep Parhar wrote: >> On a very recent clang-built HEAD, I see that some static structures >> have a ".n" appended to their name. For example, this declaration in >> the cxgbe driver now results in a t4_list.0 symbol in the KLD: >> >> static SLIST_HEAD(, adapter) t4_list; >> >> # nm if_cxgbe.ko | grep t4_list >> 0000000000000020 b t4_list.0 >> >> gcc used to leave it as t4_list. One problem is that kgdb can't display >> such an item (it interprets the dot as a delimiter between a structure >> and its element). Some of the structures listed at the end look strange >> for other reasons too -- for example, why should there be multiple >> scsi_low_statics.n symbols when there's only one such structure in >> scsi_low.c? >> >> Regards, >> Navdeep >> >> >> full list of affected structures (and some false positives?): >> # nm kernel *.ko | grep '\.[0-9]$' >> ffffffff814802d0 b accept_filtlsthd.0 >> ffffffff8125ca88 b acpi_intr_list.0 >> ffffffff81292278 b cdevsw_gt_post_list.0 >> ffffffff812defc8 b clock_adj.0 >> ffffffff812defd0 b clock_adj.1 >> ffffffff814d7ac0 b enumerators.0 >> ffffffff81292460 b eventtimers.0 >> ffffffff81279680 b feedertab.0 >> ffffffff81248470 d intr_cpus.0.0 >> ffffffff814a0378 b keyboard_drivers.0 >> ffffffff81481c60 b lltables.0 >> ffffffff814a17a8 b profperiod.1 >> ffffffff81482280 b route_cb.0 >> ffffffff81482284 b route_cb.1 >> ffffffff81482288 b route_cb.2 >> ffffffff8148228c b route_cb.3 >> ffffffff812796d0 b sndstat_devlist.0 >> ffffffff814a17a0 b statperiod.1 >> ffffffff812925a4 b tstate.0 >> ffffffff812925a8 b tstate.1 >> ffffffff8128ab30 b twe_check_bits.lastwarn.0 >> ffffffff8128ab38 b twe_check_bits.lastwarn.1 >> ffffffff814804d8 b unp_defers.0 >> ffffffff81488760 b vm_phys_lookup_lists.0 >> ffffffff813e7900 b w_hash.0 >> ffffffff813e80dc b w_hash.2 >> ffffffff813e58f0 b w_lohash.0 >> ffffffff813e78dc b w_lohash.2 >> 0000000000000318 d proto_reg.0 >> 000000000000031c d proto_reg.1 >> 00000000000000c0 b fasttrap_procs.0 >> 00000000000000c8 b fasttrap_procs.1 >> 00000000000000d0 b fasttrap_procs.2 >> 0000000000000080 b fasttrap_provs.0 >> 0000000000000088 b fasttrap_provs.1 >> 0000000000000090 b fasttrap_provs.2 >> 0000000000000028 b t3_list.0 >> 0000000000000050 b t3_uld_list.0 >> 0000000000000020 b t4_list.0 >> 0000000000000048 b t4_uld_list.0 >> 0000000000000000 b efdev.0 >> 0000000000000190 b Counter.0 >> 0000000000000194 b Counter.1 >> 0000000000000198 b Counter.2 >> 000000000000019c b Counter.3 >> 0000000000000028 b taphead.0 >> 0000000000001190 b svc_rpc_gss_callbacks.0 >> 0000000000001198 b svc_rpc_gss_svc_names.0 >> 0000000000000038 b scsi_low_statics.0 >> 000000000000003c b scsi_low_statics.1 >> 0000000000000040 b scsi_low_statics.2 >> 0000000000000044 b scsi_low_statics.3 >> 0000000000000048 b scsi_low_statics.4 >> 0000000000000008 b feedertab.0 >> 0000000000000098 b sndstat_devlist.0 >> 0000000000000008 b pcx_info.0 >> 000000000000000c b pcx_info.1 >> 0000000000000010 b pcx_info.2 >> 0000000000000014 b pcx_info.3 >> 0000000000000018 b pcx_info.4 >> 000000000000001c b pcx_info.5 >> 0000000000000020 b pcx_info.6 >> 0000000000000028 b pcx_info.7 >> 0000000000000000 b twe_check_bits.lastwarn.0 >> 0000000000000008 b twe_check_bits.lastwarn.1 >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"