[MLton] stripping executables

[Matthew Fluet]

[Moving from mlton-user to mlton.]

On Sat, 15 Dec 2007, Vesa Karvonen wrote:
> On Dec 15, 2007 3:43 PM, Matthew Fluet <fluet at tti-c.org> wrote:
>> On Wed, 12 Dec 2007, Vesa Karvonen wrote:
> [...]
>>> Looking at man ld shows option:
>>>
>>>       -s
>>>       --strip-all
>>>           Omit all symbol information from the output file.
>>>
>>> Specifying -link-opt -s to MLton seems to have the same effect as
>>> compiling with MLton and then separately stripping the executable.
>>>
>>> Perhaps -s should be specified by default and omitted when -debug true
>>> is explicitly specified.
>>
>> When gcc compiles an executable, it doesn't strip, so I'm not sure that it
>> is the right option to always strip.
>
> Well, I don't know for sure either.  However, googling a bit and
> reading some man pages, I get the impression that it should be safe to
> strip executables.  I guess it may have been historically unsafe (e.g.
> stripping symbols needed for relocation), but I get the impression
> that it isn't the case anymore.  OTOH, I get the impression that
> stripping shared libs may cause problems.  The (non-debug) symbols are
> needed in shared libs to make it possible to link to the library
> dynamically.

My concerns with passing '-s' by default to gcc/ld are that: 1) it is not 
the default gcc/ld behavior; 2) it is an irreversable action on the 
executable; 3) there's no way to override the behavior.

It is unfortunate that there is no option to pass to gcc/ld that overrides 
the '-s' behavior, because if we were to make '-s' the default in mlton, 
we'd need to have a mlton option to override the behavior, rather than 
being able to use a '-link-opt' option.  Going down this path, we could 
end up duplicating a lot of gcc/ld/as options as mlton options.

It probably makes more sense to tweak the x86 and amd64 codegens to emit 
labels that are recognized as local labels by the assembler (and stripped 
from the object file).  Though, that means baking in yet more platform 
dependent knowledge.