Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Nov 2012 14:04:15 -0800
From:      Navdeep Parhar <nparhar@gmail.com>
To:        Roman Divacky <rdivacky@freebsd.org>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: clang mangling some static struct names?
Message-ID:  <50A6B85F.6090707@gmail.com>
In-Reply-To: <20121116214919.GA41725@freebsd.org>
References:  <50A6A3BD.5000901@gmail.com> <20121116214919.GA41725@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50A6B85F.6090707>