[libbdf] Mach-O format support ?

[libbdf] Mach-O format support ?

[Emmanuel Fleury]

Hi all,

I'm using libbfd as a binary loader for some project and I noticed that
it has some problems with most of the Mach-O (but not all).

Could somebody tell me what criteria make a Mach-O binary readable or
not. And, if there are some plan to support them all (in the future) ?

It seems that Apple is using otools, but I really dont want to dig in it. :)

Thanks in advance.

Regards
--
Emmanuel Fleury

Re: [libbdf] Mach-O format support ?

[Tristan Gingold]

On Apr 13, 2010, at 5:07 PM, Emmanuel Fleury wrote:

> Hi all,
> 
> I'm using libbfd as a binary loader for some project and I noticed that
> it has some problems with most of the Mach-O (but not all).
> 
> Could somebody tell me what criteria make a Mach-O binary readable or
> not. And, if there are some plan to support them all (in the future) ?

Hi,

it is difficult to answer to such a vague question.  The handling of Mach-O in bfd is good enough to
have tools such as objdump working as well as gdb.

If you can describe precisely your issue (a reproducer would be welcome), then I could start to
investigate.

Tristan.

Re: [libbdf] Mach-O format support ?

[Emmanuel Fleury]

Tristan Gingold wrote:
> 
> it is difficult to answer to such a vague question.  The handling of Mach-O in bfd is good enough to
> have tools such as objdump working as well as gdb.
> 
> If you can describe precisely your issue (a reproducer would be welcome), then I could start to
> investigate.

Yes, you're definitely right, my description was extremely loose.
I first thought that the binutils dev team had a "position" on not
supporting part of the Mach-O. So, I did dig a bit and I think I might
have found what is going on.


More precisely, on my Debian-based computer when attempting to
disassemble one of those problematic Mach-O, I get the following:

[================================================================]
[fleury@aldebaran bfd-macho]$ file ls.macos
ls.macos: Mach-O fat file with 2 architectures
[fleury@aldebaran bfd-macho]$ objdump -d ls.macos
objdump: ls.macos: File format not recognized
[================================================================]


And, indeed, objdump is not responsible of this problem because I
experiment the exact same problem with my own program when using the
bfd_perror() function.

Concerning my version of binutils:

[================================================================]
ii  binutils                                                2.20.1-5
                        The GNU assembler, linker and binary utilities
ii  binutils-dev                                            2.20.1-5
                        The GNU binary utilities (BFD development files)
ii  binutils-doc                                            2.20.1-5
                        Documentation for the GNU assembler, linker and
binary utilities
ii  binutils-multiarch                                      2.20.1-5
                        Binary utilities that support multi-arch targets
ii  mingw32-binutils                                        2.20-0.1
                        Minimalist GNU win32 (cross) binutils
[================================================================]


On a Mac OS X computer, I have:

[================================================================]
punta:insight labri$ file /bin/ls
/bin/ls: Mach-O universal binary with 2 architectures
/bin/ls (for architecture i386): Mach-O executable i386
/bin/ls (for architecture ppc7400):     Mach-O executable ppc
[================================================================]

And for software coming from MacPorts:

[================================================================]
punta:insight labri$ file /opt/local/bin/svn
/opt/local/bin/svn: Mach-O executable i386
[================================================================]

The binary from MacPorts can be accessed with no problem, on the
contrary of the one from /bin.

So, what I suspect is just that libbfd does not handle this 'multi-arch'
packaging feature that seems to be supported in Mach-O.

Is it right ?

And, then, a natural question would be: Is there anyone working on
support for this ?

Regards
-- 
Emmanuel Fleury

When it comes to software security, the devil is in the details.
  -- Bruce Schneier

Re: [libbdf] Mach-O format support ?

[Tristan Gingold]

On Apr 14, 2010, at 10:07 AM, Emmanuel Fleury wrote:
> 
> So, what I suspect is just that libbfd does not handle this 'multi-arch'
> packaging feature that seems to be supported in Mach-O.
> 
> Is it right ?

No, this works for me, using the current head (should also work with 2.21):

$ ./binutils/objdump -f /bin/ls 
In archive /bin/ls:

/bin/ls:i386:x86-64:     file format mach-o-x86-64
architecture: i386:x86-64, flags 0x00000012:
EXEC_P, HAS_SYMS
start address 0x0000000100001478


/bin/ls:i386:     file format mach-o-i386
architecture: i386, flags 0x00000012:
EXEC_P, HAS_SYMS
start address 0x00001a60

Tristan.

Re: [libbfd] Mach-O format support ?

[mpsuzuki]

Hi,

How about "nm" for universal binary?

If I execute "nm" of latest binutils (downloaded from CVS)
and try for universal binary archive (/usr/lib/libwrap.a)
on Mac OS X, "nm" complains as:

$ ./nm-new /usr/lib/libwrap.a 
./nm-new: /usr/lib/libwrap.a:i386: File format not recognized
./nm-new: /usr/lib/libwrap.a:powerpc:common: File format not recognized

Nothing to say, "objdump -f" works well as you replied.

Regards,
mpsuzuki

On Wed, 14 Apr 2010 10:27:31 +0200
Tristan Gingold <gingold@adacore.com> wrote:
>On Apr 14, 2010, at 10:07 AM, Emmanuel Fleury wrote:
>> So, what I suspect is just that libbfd does not handle this 'multi-arch'
>> packaging feature that seems to be supported in Mach-O.
>> 
>> Is it right ?
>
>No, this works for me, using the current head (should also work with 2.21):
>
>$ ./binutils/objdump -f /bin/ls 
>In archive /bin/ls:
>
>/bin/ls:i386:x86-64:     file format mach-o-x86-64
>architecture: i386:x86-64, flags 0x00000012:
>EXEC_P, HAS_SYMS
>start address 0x0000000100001478
>
>
>/bin/ls:i386:     file format mach-o-i386
>architecture: i386, flags 0x00000012:
>EXEC_P, HAS_SYMS
>start address 0x00001a60
>
>Tristan.
>

Re: [libbfd] Mach-O format support ?

[Tristan Gingold]

On Apr 14, 2010, at 10:39 AM, mpsuzuki@hiroshima-u.ac.jp wrote:

> Hi,
> 
> How about "nm" for universal binary?

nm on universal binary works too.

> If I execute "nm" of latest binutils (downloaded from CVS)
> and try for universal binary archive (/usr/lib/libwrap.a)
> on Mac OS X, "nm" complains as:
> 
> $ ./nm-new /usr/lib/libwrap.a 
> ./nm-new: /usr/lib/libwrap.a:i386: File format not recognized
> ./nm-new: /usr/lib/libwrap.a:powerpc:common: File format not recognized

Yes, nm on universal archive doesn't work, because nm doesn't handle archives of archives!

Tristan.

Re: [libbfd] Mach-O format support ?

[mpsuzuki]

Hi,

On Wed, 14 Apr 2010 10:49:02 +0200
Tristan Gingold <gingold@adacore.com> wrote:
>> on Mac OS X, "nm" complains as:
>> 
>> $ ./nm-new /usr/lib/libwrap.a 
>> ./nm-new: /usr/lib/libwrap.a:i386: File format not recognized
>> ./nm-new: /usr/lib/libwrap.a:powerpc:common: File format not recognized
>
>Yes, nm on universal archive doesn't work, because nm doesn't handle archives of archives!

Thank you for quick reply!

It seems that the "ar" of GNU binutils doesn't handle
universal binary archive directly. I guess the universal
binary archive of Mac OS X is concatenated in fat binary
format, instead of "ar" archive format. In fact, even
Apple's "ar" cannot parse the universal binary archive,
it tells to split the universal binary archive by libtool/lipo
and execute "ar" on the splitted files.

Is there GNU replacement of Apple's lipo?

Regards,
mpsuzuki

Re: [libbfd] Mach-O format support ?

[Tristan Gingold]

On Apr 14, 2010, at 11:11 AM, mpsuzuki@hiroshima-u.ac.jp wrote:

> Hi,
> 
> On Wed, 14 Apr 2010 10:49:02 +0200
> Tristan Gingold <gingold@adacore.com> wrote:
>>> on Mac OS X, "nm" complains as:
>>> 
>>> $ ./nm-new /usr/lib/libwrap.a 
>>> ./nm-new: /usr/lib/libwrap.a:i386: File format not recognized
>>> ./nm-new: /usr/lib/libwrap.a:powerpc:common: File format not recognized
>> 
>> Yes, nm on universal archive doesn't work, because nm doesn't handle archives of archives!
> 
> Thank you for quick reply!
> 
> It seems that the "ar" of GNU binutils doesn't handle
> universal binary archive directly.

It can.  It just see the universal binary as an archive.  Eg:

$ ./binutils/ar tv /bin/ls 
/bin/ls:i386:x86-64
/bin/ls:i386

>  I guess the universal
> binary archive of Mac OS X is concatenated in fat binary
> format, instead of "ar" archive format.

Yes, it is a different format.

> In fact, even
> Apple's "ar" cannot parse the universal binary archive,
> it tells to split the universal binary archive by libtool/lipo
> and execute "ar" on the splitted files.
> 
> Is there GNU replacement of Apple's lipo?

You can use binutils ar to list or extract a member of a universal binary, but you can't build a
universal binary with binutils tools.  That's something I'd like to add, but it will require a change to
ar.

Tristan.

Re: [libbdf] Mach-O format support ?

[Emmanuel Fleury]

On 04/14/2010 10:27 AM, Tristan Gingold wrote:
> 
> No, this works for me, using the current head (should also work with 2.21):
> 
> $ ./binutils/objdump -f /bin/ls 
> In archive /bin/ls:
> 
> /bin/ls:i386:x86-64:     file format mach-o-x86-64
> architecture: i386:x86-64, flags 0x00000012:
> EXEC_P, HAS_SYMS
> start address 0x0000000100001478
> 
> 
> /bin/ls:i386:     file format mach-o-i386
> architecture: i386, flags 0x00000012:
> EXEC_P, HAS_SYMS
> start address 0x00001a60

Well, it solve the issue then.

I'll update to a fresher version of the binutils.

Thanks a lot!

Regards
--
Emmanuel Fleury

Re: [libbdf] Mach-O format support ?

[Tristan Gingold]

On Apr 14, 2010, at 10:54 AM, Emmanuel Fleury wrote:

> On 04/14/2010 10:27 AM, Tristan Gingold wrote:
>> 
>> No, this works for me, using the current head (should also work with 2.21):
>> 
>> $ ./binutils/objdump -f /bin/ls 
>> In archive /bin/ls:
>> 
>> /bin/ls:i386:x86-64:     file format mach-o-x86-64
>> architecture: i386:x86-64, flags 0x00000012:
>> EXEC_P, HAS_SYMS
>> start address 0x0000000100001478
>> 
>> 
>> /bin/ls:i386:     file format mach-o-i386
>> architecture: i386, flags 0x00000012:
>> EXEC_P, HAS_SYMS
>> start address 0x00001a60
> 
> Well, it solve the issue then.
> 
> I'll update to a fresher version of the binutils.
> 
> Thanks a lot!

You're welcome.  Thank you for using binutils.

Tristan.