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