Project Home
Project Home
Source Code
Source Code
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - QNX dumper -m option: (12 Items)
   
QNX dumper -m option  
I need to understand the details of the -m option inthe dumper; On specifying this option; I am unable to see values of 
 uninitialized globals in my core file.
Although I see the initialized globals (via the ldd-fetch routines I think) 
Re: QNX dumper -m option  
-m dumps out the stack, and only those pages that contain information 
related to the dynamic link map (required to load the
shared libray info for gdb)

The whole point of it is to not dump out data memory.  The original 
rational was to provide backtrace information, where
a full dump would be too large for the storage media.

Colin

Preeti Sharma wrote:
>
> I need to understand the details of the -m option inthe dumper; On 
> specifying this option; I am unable to see values of  uninitialized 
> globals in my core file.
>
> Although I see the initialized globals (via the ldd-fetch routines I 
> think)
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post2210
>

-- 
cburgess@qnx.com

Re: QNX dumper -m option  
Thanks for the explanation. So I need the -m option because without it my file size gets really big. Is there a way I 
can change dumper to give me the .data and/or .bss sections.
I am running on a Xscale.
Re: QNX dumper -m option  
So you want to log the .data and .bss but not heap?

Why is your dump so huge?  Are you mapping in a large device?  What 
flags do you use for that?

Preeti Sharma wrote:
>
> Thanks for the explanation. So I need the -m option because without it 
> my file size gets really big. Is there a way I can change dumper to 
> give me the .data and/or .bss sections.
>
> I am running on a Xscale.
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post2237
>

-- 
cburgess@qnx.com

Re: QNX dumper -m option  
I mentioned the .data and .bss since I need the globals (initialized and not) and the locals (should get from the stack)
.
I run with -m and -d. 
My corefile size without the -m is about 10MB.
Re: QNX dumper -m option  
It might be possible to select only those data sections that are 
MAP_ELF, since the .data and .bss sections would both
be in the executable's initial data segment.

Preeti Sharma wrote:
>
> I mentioned the .data and .bss since I need the globals (initialized 
> and not) and the locals (should get from the stack).
>
> I run with -m and -d.
> My corefile size without the -m is about 10MB.
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post2239
>

-- 
cburgess@qnx.com

Re: QNX dumper -m option  
Hmm MAP_ELF did not seem to work ....I specified it in elfcore ; where PG_HWMAPPED and MAP_STACK are checked...
Re: QNX dumper -m option  
Is there a reson for gdb to not recognize this file as a corefile...
Re: QNX dumper -m option  
BTW - is your corefile 10Mb compressed?

Preeti Sharma wrote:
>
> I mentioned the .data and .bss since I need the globals (initialized 
> and not) and the locals (should get from the stack).
>
> I run with -m and -d.
> My corefile size without the -m is about 10MB.
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post2239
>

-- 
cburgess@qnx.com

Re: QNX dumper -m option  
No uncompressed .... I am running an older version that did not support compression; although I have test results from 
the newer version too (with the get_ldd_mapinfos and compression) 
Let me try MAP_ELF ...

Thanks
Re: QNX dumper -m option  
Hmm MAP_ELF did not seem to work ....I specified it in elfcore ; where PG_HWMAPPED and MAP_STACK are checked...

 
 
Re: QNX dumper -m option  
add this  "||mapinfos[i].flags & MAP_ELF" first then

1.============
	for(seg = 0, i = 0; i < num; i++) {
	  	if(!(mapinfos[i].flags & PG_HWMAPPED) ||
			(nodumpmem && !(mapinfos[i].flags & MAP_STACK 
||mapinfos[i].flags & MAP_ELF)) ) {
			continue;
		}
		if ( (nodumpphys && (mapinfos[i].flags & MAP_PHYS) && !(mapinfos[i].flags & MAP_ANON)) ) {
			continue;
		}

		/* if we only want to dump the offending tid's stack */
		if(cur_tid_only && (mapinfos[i].flags & MAP_STACK) && 
			!OFFENDING_THREAD(cur_tid_base, cur_tid_size, &mapinfos[i])) {
			continue;
		}

		memcpy(&mem[seg], &mapinfos[i], sizeof(*mem));
		seg++;
	}

2.==============
add || mem[j].flags & MAP_ELF

for ( j = 0; j < seg; j++ ) {
		if ( lseek( fd, mem[j].vaddr, SEEK_SET ) == -1 )
			goto bailout;
		if ( mem[j].flags & MAP_STACK || mem[j].flags & MAP_ELF)
			dump_stack_memory( fd, fp, &mem[j], &coresize );
		else
		  if (!nodumpmem)
			dump_memory( fd, fp, &mem[j], &coresize );
	}

this should work.
if this doesn't work then it is possible that some areas we dumped twice, take a look dump_stack_memory should tell us.