it should be

extern struct r_debug _r_debug; // see underscore.

On Wed, 2010-12-08 at 12:54 -0500, Kevin Stallard wrote:
> Collin,
> 
> extern struct r_debug r_debug;
> 
> This is coming up as an undefined reference when linking.  Is there a
> lib I need to include?
> 
> Thanks
> Kevin
> 
> 
> 
> 
> _______________________________________________
> 
> General
> http://community.qnx.com/sf/go/post77860
> 
> 
> 

that's _r_debug, not r_debug

On 10-12-08 12:54 PM, Kevin Stallard wrote:
>
> Collin,
>
> extern struct r_debug r_debug;
>
> This is coming up as an undefined reference when linking.  Is there a 
> lib I need to include?
>
> Thanks
> Kevin
>
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post77860
>

-- 
cburgess@qnx.com

Was this viewed via gdb, or your own printfs?

On 10-12-08 1:20 PM, Kevin Stallard wrote:
> Hey Colin,
>
> r_map is null before and after I load io-blk.  Here are all the members of r_debug (after dlopen() is called).
>
>
> rdbg	0x48063c40	
> 	r_version	2	
> 	r_map	0x00000000	
> 	r_brk	4264800944	
> 	r_state	RT_CONSISTENT	
> 	r_ldbase	0	
> 	r_ldsomap	0x00000000	
> 	r_rdevent	RD_NONE	
> 	r_flags	RD_FL_NONE	
>
>
> Thanks
> Kevin
>
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post77882
>

-- 
cburgess@qnx.com

#include <stdio.h>
#include <sys/link.h>

extern struct r_debug _r_debug;

int main(void)
{
     Link_map *l;

     for( l = _r_debug.r_map; l != NULL; l = l->l_next ) {
         printf("l_addr:     %#x\n", l->l_addr );
         printf("l_name:     %s\n", l->l_name?:"(NULL)" );
         printf("l_ld:       %p\n", l->l_ld );
         printf("l_next:     %p\n", l->l_next );
         printf("l_prev:     %p\n", l->l_prev );
         printf("l_prev:     %p\n", l->l_prev );
         printf("l_loaded:   %#x\n", l->l_loaded );
         printf("l_path:     %s\n", l->l_path );
         printf("\n");
     }

     return 0;
}

# qcc -Vgcc_ntoarmv7le -o ldd ldd.c -lsocket -lm -lz

...

# /Users/cburgess/ldd
ldd
l_addr:        0x100000
l_name:        (NULL)
l_ld:          1019f8
l_next:        202400
l_prev:        0
l_prev:        0
l_loaded:    0x4cffcc04
l_path:        /Users/cburgess/ldd

l_addr:        0x78110000
l_name:        libsocket.so.3
l_ld:          7813b734
l_next:        202800
l_prev:        202000
l_prev:        202000
l_loaded:    0x4cffcc04
l_path:        /base/lib/libsocket.so.3

l_addr:        0x780e0000
l_name:        libm.so.2
l_ld:          78106010
l_next:        202c00
l_prev:        202400
l_prev:        202400
l_loaded:    0x4cffcc04
l_path:        /base/lib/libm.so.2

l_addr:        0x78150000
l_name:        libz.so.2
l_ld:          78164afc
l_next:        203000
l_prev:        202800
l_prev:        202800
l_loaded:    0x4cffcc04
l_path:        /base/usr/lib/libz.so.2

l_addr:        0x10f0000
l_name:        libc.so.3
l_ld:          116a6d8
l_next:        0
l_prev:        202c00
l_prev:        202c00
l_loaded:    0x4cffcc04
l_path:        /usr/lib/ldqnx.so.2


On 10-12-08 1:20 PM, Kevin Stallard wrote:
> Hey Colin,
>
> r_map is null before and after I load io-blk.  Here are all the members of r_debug (after dlopen() is called).
>
>
> rdbg	0x48063c40	
> 	r_version	2	
> 	r_map	0x00000000	
> 	r_brk	4264800944	
> 	r_state	RT_CONSISTENT	
> 	r_ldbase	0	
> 	r_ldsomap	0x00000000	
> 	r_rdevent	RD_NONE	
> 	r_flags	RD_FL_NONE	
>
>
> Thanks
> Kevin
>
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post77882
>

-- 
cburgess@qnx.com

Please print this before and after dlopen and specify if it is with or
without profiling. Could you, actually, do that for both profiled and
non-profiling case?

I have a feeling there is a bug in 6.3.2 ldd triggered by profiling
harness.




On Wed, 2010-12-08 at 13:20 -0500, Kevin Stallard wrote:
> Hey Colin,
> 
> r_map is null before and after I load io-blk.  Here are all the
> members of r_debug (after dlopen() is called).
> 
> 
> rdbg    0x48063c40     
>         r_version       2      
>         r_map   0x00000000     
>         r_brk   4264800944     
>         r_state RT_CONSISTENT  
>         r_ldbase        0      
>         r_ldsomap       0x00000000     
>         r_rdevent       RD_NONE
>         r_flags RD_FL_NONE     
> 
> 
> Thanks
> Kevin
> 
> 
> 
> 
> _______________________________________________
> 
> General
> http://community.qnx.com/sf/go/post77882
> 
> 
> 

Wow, maybe you're right... :-)

On 10-12-07 10:28 PM, Aleksandar Ristovski wrote:
>
> I looked at link.h from my 6.3.2 installation. Unless I messed up my
> installation.
>
> On Tue, 2010-12-07 at 22:06 -0500, Colin Burgess wrote:
> > ldd_handler was not in ldd back in 6.3.2 was it?
> >
> > On 10-12-07 9:58 PM, Aleksandar Ristovski wrote:
> > >
> > > I don't think it is related in this case - gdb gets its shared
> > object
> > > list from ldd runtime link map.
> > >
> > > I would like to rule out gdb as the culprit. Could you do the
> > following
> > > test and post the result?
> > >
> > > ----------------- 8< ----------------
> > >
> > > #include <sys/link.h>
> > > #include <stdio.h>
> > > #include <dlfcn.h>
> > >
> > > int ldd_handler(Ldd_Eh_Data_t *ehd, void *eh_d_handle, unsigned
> > flags)
> > > {
> > >         printf("soname: %s\n", ehd->l_map->l_name ?
> > ehd->l_map->l_name :
> > > "executable");
> > > }
> > >
> > > void list_dlls(void)
> > > {
> > >         void *const eh = __ldd_register_eh(ldd_handler, NULL,
> > > LDD_EH_DLL_REPLAY | LDD_EH_DLL_LOAD);
> > >
> > >         __ldd_deregister_eh(eh);
> > > }
> > >
> > > int main(int argc, char *argv[]) {
> > >         void *h = dlopen("io-blk.so", RTLD_NOW);
> > >
> > >         /* Put a breakpoint on the next line: */
> > >         if (h == NULL) {
> > >         /* While at the breakpoint, do from gdb:
> > >            (gdb) print list_dlls()
> > >            */
> > >                 printf("Failed\n");
> > >         } else {
> > >                 printf("Succeeded\n");
> > >         }
> > >         return 0;
> > > }
> > >
> > > ----------------- >8 ----------------
> > >
> > > On Tue, 2010-12-07 at 15:52 -0500, Elena Laskavaia wrote:
> > > > So try to put library not in shmem - do you have flash or mounted
> > > > drive you can use?
> > > >
> > > > On 07/12/10 03:17 PM, Kevin Stallard wrote:
> > > > > Hey Aleksandar,
> > > > >
> > > > > Thanks for helping out with this.  I would say don't worry about
> > it.
> > > > I need to either come up with a solution to our throughput problem
> > > > quickly or we just live with it.  There is a lot of pressure to
> > fix
> > > > it, but even the support channels may take too long.  I was just
> > > > hoping there was a quick fix.
> > > > >
> > > > > I have other avenues to follow, so let's drop it for now.  If
> > you
> > > > happen to have some insights or ideas, do share, but I wouldn't
> > spend
> > > > any time on it.
> > > > >
> > > > > Thanks for all the time you spent with me yesterday evening, I
> > > > appreciate it very much.
> > > > >
> > > > > Sincerely,
> > > > > Kevin
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > >
> > > > > General
> > > > > http://community.qnx.com/sf/go/post77677
> > > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > >...

oh, and one more thing: the output will actually be printed in your program console.

soname: executable
soname: libcam.so.2
soname: libm.so.2
soname: libc.so.2
soname: io-blk_g.so

This is with profiling enabled.  It still doesn't show up in 'info shared'

Kevin