Porting to OS X

[goxberry]

I've been interested in using mpiP to try and understand some parallel bugs I've been having, and I like to use my laptop for small-scale debugging, so I started porting mpiP over to OS X.

I have a build that works without BFD or libelf/libdwarf support in spack/spack#7146. The patch therein is inelegant, and I suspect there is a simpler one that will work better, but it's a starting point. Would the devs on this project be interested in a patch if I file a PR?

I also have a branch of spack that builds mpiP on OS X with libelf/libdwarf support, and I can build examples, but libdwarf throws an error in mpip (Code 134, DW_DLE_ARANGE_OFFSET_BAD: The debug_arange entry has a DIE offset that is larger than the size of the .debug_info section). I suspect this error might be due to spack packages inconsistently using GNU libtool or Apple's BSD libtool, but was wondering if you guys might have more insight into that bug, or interest in that capability.

[goxberry]

Managed to get bfd support working also, and native system libunwind support.

[cchambreau]

Hi Geoffrey, Glad to hear about your successes! I am fine with the change to spack package file. To tell you the truth, I haven’t tested mpip with spack much, so I suppose it is good to hear that it is working. I’m happy to add the malloc patch to mpiPi.h.in if that eliminates the need for a spack patch file.

…

-Chris From: Geoffrey Oxberry <[email protected]> Reply-To: LLNL/mpiP <[email protected]> Date: Thursday, February 1, 2018 at 4:11 AM To: LLNL/mpiP <[email protected]> Cc: Subscribed <[email protected]> Subject: Re: [LLNL/mpiP] Porting to OS X (#2) Managed to get bfd support working also, and native system libunwind support. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#2 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ARolReGH3803IKZJIVh__i6WXk9DVsnGks5tQY21gaJpZM4R1QpQ>.

[goxberry]

Sounds good! I'll submit two PRs this weekend.

The first would be a patch to get base mpiP functionality working.

The second would be patches for BFD support.

I'm still interested in trying to get libelf/libdwarf support working also, but I'm not sure how to proceed there. I have some ideas (trying alternate versions of libelf and libdwarf like the ones in Apple's dtrace library, or elftoolchain; also trying to improve spack's support of darwin's build toolchains), but those are really just guesses -- I don't have a good sense of how to narrow down the problem further.

[tgamblin]

@goxberry: are you trying to get libelf/libdwarf working to get symbol info? I'm not sure that is the way to go, as OS X doesn't even use ELF. Its binaries are mach-o. You'd likely need to add some support for non-elf binaries.

[goxberry]

@tgamblin Good point! The situation on OS X is weird; there are ELF libraries in some places, I don't know why. I know pretty much nothing about how shared libraries work. I'm looking at setting up a Linux environment locally so I don't have to worry about Mach-O vs ELF, and I can still play with some of the interesting instrumentation libraries to figure out what's going on with my MPI code.

The patch re: BFD should be cross-platform; their devs are stubborn about insisting that the macros PACKAGE and VERSION are defined.

It seems like if someone wanted to figure out the Mach-O equivalent to traversing the link_map in the _r_debug_ data structure, the answer would be buried in the headers in /usr/include/mach-o. I don't know that it's really worth doing so.

[bkmgit]

On linux, one needs to get the config.h file in the bfd build subdirectory of the binutils build directory. This has defines PACKAGE to be binutils and also gets the version of binutils. It also has a number of other platform specific configuration options - https://sourceware.org/ml/binutils/2018-11/msg00247.html