Page MenuHomeFreeBSD

objcopy: restore behaviour required by GCC's build

Authored by emaste on Oct 17 2018, 1:33 PM.
Referenced Files
Unknown Object (File)
Sun, Feb 11, 8:48 PM
Unknown Object (File)
Tue, Jan 30, 8:02 PM
Unknown Object (File)
Dec 23 2023, 2:09 AM
Unknown Object (File)
Dec 19 2023, 1:19 PM
Unknown Object (File)
Nov 27 2023, 8:52 PM
Unknown Object (File)
Oct 7 2023, 10:25 AM
Unknown Object (File)
Aug 15 2023, 1:49 PM
Unknown Object (File)
Aug 15 2023, 1:39 PM



In rS339350 (D17519) filter_reloc() was removed, to fix the case of stripping statically linked binaries with relocations (which may come from ifunc use, for example). As a side effect this changed the behaviour when stripping object files - the output was broken both before and after rS339350 in different ways. Unfortunately GCC's build process relies on the previous behaviour, so:

  • Revert rS339350, restoring filter_reloc().
  • Fix an unitialized variable use (commited as r3638 in ELF Tool Chain).
  • Change filter_reloc() to omit relocations referencing removed symbols, while retaining relocations with no symbol reference.

(Note this review represents only the third change.)

Test Plan
  • strip a .o file, observe relocations have been removed
  • strip a statically linked binary containing ifunc, observe sym-less relocation remains

Diff Detail

rS FreeBSD src repository - subversion
Lint Not Applicable
Tests Not Applicable

Event Timeline

This comment has been deleted.
kaiw requested changes to this revision.Oct 18 2018, 6:56 PM

Ed, patch looks good. Just need a small change. When symbol table does not exist in the output, we need to check
and skip relocation sections for dynamic symbols. Otherwise strip will segfault when called on dynamic linked executables
that's already stripped.

This revision now requires changes to proceed.Oct 18 2018, 6:56 PM

I've emailed you a modfied patch.

I applied the new patch and all the test cases passed!

This revision is now accepted and ready to land.Oct 18 2018, 8:35 PM

Thanks for tackling this, Ed.

Do I read this correctly that once this is applied, the lang/gcc* ports should be bootstrapping fine again? Or do we need to look into further changes related to those?

Do I read this correctly that once this is applied, the lang/gcc* ports should be bootstrapping fine again?

Correct, they should.

This revision was automatically updated to reflect the committed changes.