Re: Re: GNU strip fails to set sh_link and sh_info on Solaris SPARC64

[Libor Bukata]

Hi Nick,

On 3/5/21 12:11 PM, Nick Clifton wrote:
> Hi Libor,
>
> > thank you for ideas. Obviously, the biggest problem is that we know 
> > too late whether the symbol section is empty and it is difficult to 
> > remove already created output sections (requires hacks). In that 
> > case, a safer and cleaner solution (but slow) is to call strip in two 
> > phases> Not sure whether I should attempt to implement it since this 
> > performance bottleneck could be no-go.
>
> Safe and slow but working is better than fast and broken...
I discussed the issue with Ali Bahrami and there is 1-1 mapping between 
.symtab and .SUNW_sym*sort sections. In other words, if some symbols are 
striped from .symtab (very likely), it makes sort sections unusable.
> I forgot whther you said that having these sections present in a file 
> when the symbol table is missing actually causes problems with their 
> execution.
I have not encountered any runtime issues during the execution, the 
runtime editor simply ignores these sections.

The only problem is that ELF binary contains orphaned sections that 
points to .symtab:
$ gstrip test
gstrip: stGfAJVb: failed to find link section for section 28
gstrip: stGfAJVb: failed to find link section for section 28
gstrip: stGfAJVb: failed to find link section for section 29
gstrip: stGfAJVb: failed to find link section for section 29

Even if .symtab section is shorten and .SUNW_sym*sort sections are kept, 
the binary still runs fine.

>   If it does not then the simplest solution is to do nothing and just 
> leave them in.  (A slightly better solution would be to add a comment 
> to the code explaining why the sections are not removed).

Or we can simply remove them unconditionally on Solaris since they are 
not mandatory for binary execution.

Thank you for your help. Ali Bahrami gives you regards.

Cheers,
Libor

> Cheers
>   Nick