Date: Sun, 18 Nov 2012 08:59:05 -0800 From: Alfred Perlstein <bright@mu.org> To: Dimitry Andric <dim@FreeBSD.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Roman Divacky <rdivacky@freebsd.org>, Navdeep Parhar <nparhar@gmail.com> Subject: Re: clang mangling some static struct names? Message-ID: <A6F279A6-99E6-4918-A780-1FAFA48F3E62@mu.org> In-Reply-To: <50A8E487.1020105@FreeBSD.org> References: <50A6A3BD.5000901@gmail.com> <20121116214919.GA41725@freebsd.org> <50A6B85F.6090707@gmail.com> <50A8E487.1020105@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 18, 2012, at 5:37 AM, Dimitry Andric <dim@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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A6F279A6-99E6-4918-A780-1FAFA48F3E62>