crazy idea: Make all temporary symbols unnamed

[Duncan P. N. Exon Smith]

> On 2015 Jun 17, at 13:51, Nick Kledzik <kledzik at apple.com> wrote:
> 
> 
> On Jun 17, 2015, at 10:28 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> 
>> +grosbach,kledzik
>> 
>>> On 2015 Jun 17, at 10:09, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>>> 
>>> The attached patch is a work in progress.
>>> 
>>> What it does is make all symbols that would otherwise start with a .L
>>> (or L on MachO) unnamed.
>>> 
>>> There are two issues to be aware of:
>>> 
>>> * Some of these symbols can show up in the symbol table.
>>> * We still want to produce binary identical files when going through
>>> assembly files.
>>> 
>>> If the first one is handled, the second one goes away by making sure
>>> we ignore the name of *all* .L symbols: we pick one when writing
>>> assembly, but it never shows up in the final .o.
>> 
>> How do the 'l' symbols fit into this?  Unaffected, right?
>> 
>>> In this patch I have handled the first issue only in the ELF writer by
>>> supporting unnamed symbols.
>>> 
>>> Can symbols be unnamed on COFF and MachO?
>> 
>> Nick?
> In general ‘L’ symbols are assembler-time symbols.  They don’t make it into the .o file.
> 
> Are you asking if in the few places where ‘L’ symbols make into the .o file, can their names be changed to be the empty string?    If so, as long as the symbols are non-external, they can have duplicate names (for instance you can have a static function _foo in two .o files and use ld -r to merge them and the two static _foo symbols continue to work properly).  
> 
> I don’t know off hand if anything will break if you have some nlist entries point to an empty string.  

Based on this:
https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachORuntime/index.html#//apple_ref/c/tag/nlist_64

it seems like empty strings are allowed, so if duplicate names are fine
too then it seems worth a try.

> 
> Is this patch about heap savings during the generation of .o files? or about reducing the size of .o files?

I think more about heap savings and cleaning up the code when generating
object files.