Hello,
Thanks for the response, Gene.
For now I'm just looking for a quick workaround, and if I manage to work it
out I'll make an effort to find a permanent solution.
Here's what I came up with so far:
1.
In order to load the correct dmtcphijack.so library, I've overridden the
file lookup
using jalib::Filesystem::FindHelperUtility in dmtcp/src/dmtcp_checkpoint.cpp.
Instead, I'm just using:
preloadLibs += "dmtcphijack.so";
Since both 32-bit and 64-bit libraries are in my path, the correct
dmtcphijack is loaded according to the program's compilaton (I've also
verified it using strace).
2.
My next step was changing the way libmtcp.so is loaded. In order to do
that, I've modified the find_and_open_mtcp_so function
in dmtcp/src/mtcpinterface.cpp.
It's just a quick and dirty solution in which I first try to load the
64-bit version of libmtcp.so (using a hard coded path), and if failed
trying to load 32-bit libmtcp.so.
3.
Then, I've compiled dmtcp twice: First using the --enable-m32 flag, and
then without. I made sure the object files were created in different
directories in both cases (lib and lib64).
As I said, from looking in strace output, it seems that the correct version
of dmtcphijack.so is loaded.
The problem is that when trying to run a 32-bit compiled program under
dmtcp, the program never gets to loading libmtcp.so and crashes with
a SIGSEGV (Segmentation fault) after it finished loading all the shared
libraries (last one is libgcc_s.so.1).
31361 open("/lib/libgcc_s.so.1", O_RDONLY) = 3
31361 read(3, "\177ELF....
.......
31361 set_tid_address(0xf7c61718) = 31361
31361 rt_sigaction(SIGRTMIN, {0x4f7d56760, [], 0}, NULL, 8) = 0
31361 rt_sigaction(SIGRT_1, {0x10000004f7d56670, [], 0}, NULL, 8) = 0
31361 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
31361 getrlimit(RLIMIT_STACK, {rlim_cur=-4286578688, rlim_max=73014444031})
= 0
31361 _sysctl({0x2f7d607c4, -16976, (nil), (nil), (nil),
18446671166502752244}) = 0
31361 futex(0xf7d4d4fc, FUTEX_WAKE, 2147483647) = 0
31361 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
I've also tried the other way around: using a 32-bit compiled binaries, and
the same thing happened. 32-bit programs ran correctly, and 64-bit programs
crashed with SIGSEGV.
Do you have any idea if I've missed anything?
Thanks
--Avi
On Sun, Apr 1, 2012 at 19:22, Gene Cooperman <[email protected]> wrote:
> Hi Avi,
>
> DMTCP does not have the equivalent of --enable-multilib. Based on your
> e-mail, I guess you've already seen "./configure --enable-m32" in DMTCP.
> But as you note, this supports only all processes in 32-bit mode or
> all in 64-bit mode.
>
> In principle, DMTCP could certainly be extended to support multilib.
> But this would take some effort. I don't anticipate us doing it soon,
> due to lack of resources. But we'd be very happy to help someone else do
> it,
> if they wanted to do this extension.
>
> If you wanted to look into this further, I'd be happy to schedule a phone
> call with you.
>
> Best wishes,
> - Gene
>
> On Sun, Apr 01, 2012 at 09:25:12AM +0200, Avi Rosenfeld wrote:
> > Hello,
> >
> > The environment in my workplace include programs compiled both in 64 and
> 32
> > bit on all clients. This is mainly for legacy and backward compatibility
> > reasons.
> >
> > It is not uncommon, therefore, for certain processes trees to have both
> 32
> > and 64 bit compiled programs. It's making it very hard to checkpoint such
> > applications, since DMTCP could be compiled to 32 or 64 bit, not both.
> >
> > In BLCR there's a "--enable-multilib" flag that enables building both
> > 64-bit and 32-bit libraries at the same time. Is there a way to do
> > something similar with DMTCP?
> >
> > Thanks
> > --Avi
>
> >
> ------------------------------------------------------------------------------
> > This SF email is sponsosred by:
> > Try Windows Azure free for 90 days Click Here
> > http://p.sf.net/sfu/sfd2d-msazure
>
> > _______________________________________________
> > Dmtcp-forum mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/dmtcp-forum
>
>
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Dmtcp-forum mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dmtcp-forum
