[Bug binutils/27506] New: Tmi
https://sourceware.org/bugzilla/show_bug.cgi?id=27506 Bug ID: 27506 Summary: Tmi Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: evanou at ourhealthministry dot com Target Milestone: --- Created attachment 13279 --> https://sourceware.org/bugzilla/attachment.cgi?id=13279&action=edit Web elu lemah -- You are receiving this mail because: You are on the CC list for the bug.
Re: [External] : Re: GNU strip fails to set sh_link and sh_info on Solaris SPARC64
Hi Nick, On 3/2/21 5:21 PM, Nick Clifton wrote: Hi Libor, Patch approved - please apply. thank you for your approval. How can I obtain a write permission to binutils repository? Ah right. First of all do you have a FSF Copyright assignment for the binutils ? I assume, based upon your email address, that you are working for Oracle and that this patch (and future ones) have been developed as part of your job. In which case you will be covered by Oracle's global copyright assignment and you do not have to do anything. you are right, I am working for Oracle and it has been developed as a part of my job. But if not, then a personal copyright assignment is a must. Once that is sort out, please fill out the form on this page: https://urldefense.com/v3/__https://sourceware.org/cgi-bin/pdw/ps_form.cgi__;!!GqivPVa7Brio!J3W40m_S0CuRK7XZvs0nPHRzB2304ooYq9j3yufUijfgUnYm0A4zD2AAlNdn--O_5Q$ You can use my email address as the approver. This should only take a day to complete and then you will have write access. Thank you, I have filled the form. Regards, Libor Cheers Nick
Re: Re: GNU strip fails to set sh_link and sh_info on Solaris SPARC64
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
binutils fails to compile on AIX due to mismatched declaration
The declaration for a function is incorrect; the implementation of it is missing a const. Adding a const to the implementation (line 335) is enough to fix this particular issue. rs6000-core.c:280:19: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] const bfd_cleanup rs6000coff_core_p (bfd *abfd); ^ rs6000-core.c:336:1: error: conflicting types for 'rs6000coff_core_p' rs6000coff_core_p (bfd *abfd) ^ rs6000-core.c:280:19: note: previous declaration of 'rs6000coff_core_p' was here const bfd_cleanup rs6000coff_core_p (bfd *abfd); ^
Re: binutils fails to compile on AIX due to mismatched declaration
On Wed, Mar 03, 2021 at 02:48:52PM -0400, Calvin Buckley wrote: > The declaration for a function is incorrect; the implementation of it > is missing a const. Adding a const to the implementation (line 335) is > enough to fix this particular issue. > > rs6000-core.c:280:19: warning: type qualifiers ignored on function return > type [-Wignored-qualifiers] > const bfd_cleanup rs6000coff_core_p (bfd *abfd); >^ > rs6000-core.c:336:1: error: conflicting types for 'rs6000coff_core_p' > rs6000coff_core_p (bfd *abfd) > ^ > rs6000-core.c:280:19: note: previous declaration of 'rs6000coff_core_p' was > here > const bfd_cleanup rs6000coff_core_p (bfd *abfd); rs6000-core.c is a file that uses AIX host headers so most people, including me, don't compile it. That's the excuse I'm sticking with. Committed. * rs6000-core.c (rs6000coff_core_p): Correct prototype. diff --git a/bfd/rs6000-core.c b/bfd/rs6000-core.c index 9fed1ff48b..1c19060a5d 100644 --- a/bfd/rs6000-core.c +++ b/bfd/rs6000-core.c @@ -277,7 +277,7 @@ typedef union /* Define prototypes for certain functions, to avoid a compiler warning saying that they are missing. */ -const bfd_cleanup rs6000coff_core_p (bfd *abfd); +bfd_cleanup rs6000coff_core_p (bfd *abfd); bfd_boolean rs6000coff_core_file_matches_executable_p (bfd *core_bfd, bfd *exec_bfd); char * rs6000coff_core_file_failing_command (bfd *abfd); -- Alan Modra Australia Development Lab, IBM
