clang mangling some static struct names?

[Navdeep Parhar]

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...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

[Roman Divacky]

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.

I dont know why scsi_low_statics is there multiple times.

[Navdeep Parhar]

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

[Rui Paulo]

On 16 Nov 2012, at 14:04, Navdeep Parhar <npa...@gmail.com> wrote:

> 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.

It's likely that FreeBSD's gdb has to grow support for this new symbol format. Have you tried using the newest gdb available from ports?

Regards,
--
Rui Paulo

[Dimitry Andric]

On 2012-11-16 23:04, Navdeep Parhar wrote:
> 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.

I don't think the point is making things harder for debuggers, the point
is optimization. Since static variables and functions can be optimized
away, or arbitrarily moved around, you cannot count on those symbols
being there at all.

[Alfred Perlstein]

On Nov 18, 2012, at 5:37 AM, Dimitry Andric <d...@FreeBSD.org> wrote:

> On 2012-11-16 23:04, Navdeep Parhar wrote:
>> 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.
>
> I don't think the point is making things harder for debuggers, the point
> is optimization. Since static variables and functions can be optimized
> away, or arbitrarily moved around, you cannot count on those symbols
> being there at all.

Bro, do you even debug?

[Navdeep Parhar]

On Sun, Nov 18, 2012 at 02:37:11PM +0100, Dimitry Andric wrote:
> On 2012-11-16 23:04, Navdeep Parhar wrote:
> >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.
>
> I don't think the point is making things harder for debuggers, the point
> is optimization. Since static variables and functions can be optimized
> away, or arbitrarily moved around, you cannot count on those symbols
> being there at all.

I'd (maybe) buy your argument if the symbol wasn't there at all. But
it's there, just with a .0 appended to it. It hasn't been moved around
or optimized away. In fact, in the case of scsi_low_statics the
compiler added extra noise to the binary (in the form of multiple
scsi_low_statics.[0-4] symbols that no one except the compiler knows
about).

There doesn't seem to be *any* good reason for adding the .n to the
symbols. What is the optimization being attempted here? I lost the
ability to look up some symbols in kgdb and I'd like to know what I
gained in the process :-)

Regards,
Navdeep