bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Libor Bukata
Subject: Re: Re: GNU strip fails to set sh_link and sh_info on Solaris SPARC64
Date: Wed, 3 Mar 2021 16:05:13 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0

Hi Nick,

On 3/2/21 5:36 PM, Nick Clifton wrote:
Hi Libor,

Unfortunately the above code does not work for the following reasons:

- sections are already created in that point of code
- symbol filtering requires output sections to be created
- cannot find bfd_remove_section function that could handle it

However, this code removes the sections unconditionally regardless of whether .symtab is kept or not. I can image that GNU strip could be called in two passes: the first pass could remove .symtab and .strtab sections; the second pass would strip .SUNW_sym*sort sections if .symtab section was stripped in the first pass. A big disadvantage is that it introduces double performance overhead... Any ideas?

A few - but all untested...

  * Create a hook in elf64-sparc.c for the elf_backend_section_processing() function     and have it change the section's type to SHT_NULL, so that they are ignored.
    (But still present which would be bad...)

  * Alternatively maybe the elf_backend_always_size_sections() can be used to detect
    empty symbol tables and eliminate the special sections.

  * Or the elf_backend_begin_write_processing() function could adjust the section
    header table to skip the offendng sections.

  * Add code to objcopy.c:is_strip_section_1 () that identifies these sections and
    returns TRUE if their symbol section is empty.

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.

Cheers,
Libor


Cheers
  Nick




reply via email to

[Prev in Thread] Current Thread [Next in Thread]