On Dec 16, 2011, at 10:56 AM, Nathan T. Hjelm wrote:
>> Why do the symbols need to be weak? Remember that not all platforms
>> support weak symbols.
>
> I don't know. The way we currently pull MPIR symbols into orterun breaks
> with some configuration. If we don't pull the symbols in then launch
> Why do the symbols need to be weak? Remember that not all platforms
> support weak symbols.
I don't know. The way we currently pull MPIR symbols into orterun breaks
with some configuration. If we don't pull the symbols in then launchmon
can't attach to orterun. Moving the symbols to weak fixes
Why do the symbols need to be weak? Remember that not all platforms support
weak symbols.
The symbols don't need to be in the executable itself, right? It should be
fine for them to be a library (e.g., libopen-rte.so/a).
On Dec 16, 2011, at 4:51 AM, Ashley Pittman wrote:
>
> Yes, this fixe
Yes, this fixes the issue.
Ashley.
On 15 Dec 2011, at 23:42, Nathan Hjelm wrote:
> I have an idea. How about we set those the MPIR variables as weak. Just
> tested it with STAT.
>
> Can you replace orte/tools/orterun/orterun.c with the attached version and
> see if it fixes the issue?
>
> -
I have an idea. How about we set those the MPIR variables as weak. Just tested
it with STAT.
Can you replace orte/tools/orterun/orterun.c with the attached version and see
if it fixes the issue?
-Nathan
On Thu, 15 Dec 2011, Ashley Pittman wrote:
padb just calls gdb, you can see the error u
padb just calls gdb, you can see the error using gdb alone using just the trace
I sent when I started this thread.
Perhaps the difference is in versions of gdb, I could give you a login to my
test machine if you need?
Ashley.
On 15 Dec 2011, at 22:49, Nathan Hjelm wrote:
> Whats odd is total
Whats odd is totalview, STAT, and GDB see the correct values despite them being
in the B section. What does padb do differently?
This is a dynamic, optimized build of 1.5.5rc1.
-Nathan Hjelm
HPC-3, LANL
On Thu, 15 Dec 2011, Ashley Pittman wrote:
If I add a new symbol to orte/mca/debugger/ba
If I add a new symbol to orte/mca/debugger/base/debugger_base_open.c and
declare it in orte/mca/debugger/base/base.h, the same as MPIR_proctable_size is
defined then it appears in the .so but not in the binary, if I then reference
this variable in orte/tools/orterun/orterun.c the symbol appears
+1 on Ralph's comment -- it's not on the trunk. Perhaps the CMR didn't
properly remove it from v1.5, but that explains why it's not in the v1.5
Makefile.am.
On Dec 15, 2011, at 5:08 PM, George Bosilca wrote:
> This is quite impressive. After digging a little bit more, it appears that
> the o
orte/tools/orterun/debuggers.c does not exist anymore (its not in the 1.5.5rc1
tarball). I don't know why the symbols are showing up in section B of orterun.
Investigating now.
-Nathan Hjelm
HPC-3, LANL
On Thu, 15 Dec 2011, George Bosilca wrote:
On Dec 15, 2011, at 16:55 , Ashley Pittman wr
FWIW: the makefile.am in that directory no longer includes that file, as it
should. So the file itself just needs to be deleted as the patch apparently
missed it.
On Dec 15, 2011, at 3:06 PM, Ralph Castain wrote:
> This file does not exist in the trunk, and should not exist in 1.5 any more.
>
This is quite impressive. After digging a little bit more, it appears that the
orte/tools/orterun/debuggers.c is in the repository but it is not used for
compilation. Thus, I really don't see where the second definition is coming
from?
george.
On Dec 15, 2011, at 17:02 , George Bosilca wrote
This file does not exist in the trunk, and should not exist in 1.5 any more.
Perhaps the patch for 1.5 didn't correctly delete it?
On Dec 15, 2011, at 3:02 PM, George Bosilca wrote:
> ./orte/tools/orterun/debuggers.c:142:struct MPIR_PROCDESC *MPIR_proctable =
> NULL;
> ./orte/tools/orterun/debu
That appears to be a similar problem to the MPIR_Breakpoint bug. Let me play
around and see if I can find a fix.
-Nathan Hjelm
HPC-3, LANL
On Thu, 15 Dec 2011, Ashley Pittman wrote:
There is a problem with 1.5.5rc1 that prevents padb from loading the process
table start from the orterun pro
On Dec 15, 2011, at 16:55 , Ashley Pittman wrote:
> There is a problem with 1.5.5rc1 that prevents padb from loading the process
> table start from the orterun process, what appears to be happening is that
> MPIR_proctable and MPIR_proctable_size is present in both orterun itself and
> also in
There is a problem with 1.5.5rc1 that prevents padb from loading the process
table start from the orterun process, what appears to be happening is that
MPIR_proctable and MPIR_proctable_size is present in both orterun itself and
also in libopen-rte.so, the code is correctly setting them in libo
16 matches
Mail list logo