llvm dev - May 2019 - Proposal for Mach-O support in llvm-objcopy: section renaming

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

I discussed this with Seiya off the mailing list yesterday, and this was
the suggestion we came up with, on the basis that GNU objcopy has support
for the renaming for GDB support, but it might be confusing to people who
are new to the system, so we provide a more expected output option. I'm not
experienced with MachO at all, though, so we'd appreciate any feedback from
any MachO users.

Thanks,

James

On Thu, 23 May 2019 at 05:43, Seiya Nuta <nuta at seiya.me> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190523/6a5fc83a/attachment-0001.html>

> On May 23, 2019, at 2:05 AM, James Henderson via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> I discussed this with Seiya off the mailing list yesterday, and this was
the suggestion we came up with, on the basis that GNU objcopy has support for
the renaming for GDB support, but it might be confusing to people who are new to
the system, so we provide a more expected output option. I'm not experienced
with MachO at all, though, so we'd appreciate any feedback from any MachO
users.
Generally, Mach-O tools separate the segment name and the section name as
different entries on the command line. The “<Segment Name>,<Section
Name>” string is almost always an output format. Some examples include:

	otool -s __TEXT __text /bin/ls
	ld -sectcreate __EXAMPLE __example /dev/zero ...

In my opinion, that would be ideal from a "Mach-O users" point of
view.

That said, the “two arguments” pattern isn’t very common in llvm, although it
does appear in places such as llvm-nm. llvm-objdump has a -section option that
takes a single string in the  “<Segment Name>,<Section Name>”
format. This option only applies when a Mach-O specific flag, “-macho” or
“-m", appears on the command line. And that’s basically the proposal here.
So while not ideal, it’s certainly familiar.

How will people use llvm-objcopy when the segment and section names legitimately
contain “.” or “,” characters? Will these be escapable?

The rest of the behavior, especially around “__TEXT.__text is bad but
__TEXT.__unwind_info is good”, is pretty confusing. Can we define our own
“canonical names” for canonical sections such as __unwind_info?
> 
> Thanks,
> 
> James
> 
> On Thu, 23 May 2019 at 05:43, Seiya Nuta <nuta at seiya.me
<mailto:nuta at seiya.me>> wrote:
> 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.’
Can you explain what LC_SEGMENT means here? What happens if the segment name (in
the file) does not begin with a “_”?

Thanks!

MDT
> 
> 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
<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
<https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/mach-o.c;h=d9edef2871d83b53280b613935c068e4327f3270;hb=HEAD#l90>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190523/0a1c31aa/attachment.html>