[llvm-dev] Proposal for Mach-O support in llvm-objcopy: section renaming
Seiya Nuta via llvm-dev
llvm-dev at lists.llvm.org
Wed May 22 21:43:41 PDT 2019
Hi,
I'm going to implement Mach-O support in llvm-objcopy. Before working
on this, I'd like to hear your thoughts how llvm-objcopy should handle
Mach-O section names.
By convention, Mach-O section names are denoted by "<segment
name>,<section name>". However, GNU objcopy renames them in the
following rule [1]:
- If the section name is well-known, rename it to an "canonical" name [2].
- Otherwise:
- Rename to "<segment name>.<section name>" (the separator is `.' not `,')
- If the segment name does not start with `_', prefix it with `LC_SEGMENT.'
For example, __TEXT,__text is renamed to .text and
__TEXT,__unwind_info is renamed to __TEXT.__unwind_info. For that
reason, specifying a section in command line options is rather
nonintuitive:
WRONG: objcopy --only-secton=__TEXT,__text a.out
WRONG: objcopy --only-secton=__TEXT.__text a.out
OK: objcopy --only-secton=.text a.out
WRONG: objcopy --only-secton=__TEXT,__unwind_info a.out
WRONG: objcopy --only-secton=.unwind_info a.out
OK: objcopy --only-secton=__TEXT.__unwind_info a.out
For the compatibility with GNU binutils, I propose to make this
section renaming rule as default in llvm-objcopy and implement a flag
named —macho-names to use conventional section names:
WRONG: llvm-objcopy --only-secton=__TEXT,__text a.out
WRONG: llvm-objcopy --only-secton=__TEXT.__text a.out
OK: llvm-objcopy --only-secton=.text a.out a.out2
WRONG: llvm-objcopy --macho-names --only-secton=.text a.out
WRONG: llvm-objcopy --macho-names --only-secton=__TEXT.__text a.out
OK: llvm-objcopy --macho-names --only-secton=__TEXT,__text a.out
What do you think about this behavior?
Thanks,
Seiya
[1]: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/mach-o.c;h=d9edef2871d83b53280b613935c068e4327f3270;hb=HEAD#l364
[2]: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/mach-o.c;h=d9edef2871d83b53280b613935c068e4327f3270;hb=HEAD#l90
More information about the llvm-dev
mailing list