Hi Phil,

On Thu, 2007-07-26 at 14:32 -0500, Phil Muldoon wrote:
> With apologies to Roland who coined and explained these terms to me. Any 
> errors I make here are mine, but:
> 
> elided means the segment is recorded in the program headers, but was not 
> included in the core file dump (ie filesz = 0, memsz > 0). Segments are 
> elided when they can be reconstructed after a core file dump (ie 
> segments that have not been written to).
> 
> included means both the program header and the segment itself is written 
> (ie filesz >0, memsz >0 but filesz is never more than memsz)
> 
> omitted means neither the program header entry or the segment is written 
> for that segment (ie in future it will not exist in core file 
> reconstruction).

Aha, that also explains the meaning of the new kernel /proc/sys sysctrl
parameters fs.binfmt_elf.dumpwhole_segments to get all text sections
included and fs.binfmt_elf.dump_elf_headers to get partial text sections
that I saw Roland added. Does fcore have some similar parameters?

> Yes it means that though we might have the code executable segments in 
> the core file, we lose the ability of basic navigation as _all the other 
> executable segments_ might not be there, and certainly not in an easily 
> readable/locatable way. That is why we need the executable for anything 
> other than basic segment and note access,  so we can find positional 
> information (like the link_map). The only place the executable name is 
> stored in the core file that we can get to reliably is in the 
> elf_prpsinfo notes.

Right, and elf_prpsinfo only allows for truncated executable names (16
chars). Bleah. So something like BuildID is really badly needed to
present the user with something that is more often usable I guess. I saw
that the BuildID support proposal was approved as one of the Fedora 8
Features: http://fedoraproject.org/wiki/Releases/FeatureBuildId
http://fedoraproject.org/wiki/Releases/8/FeatureList
Will it be possible for frysk to also support that in the Fedora 8
timeframe?

> > My question really is what about code segments that are modified (as we
> > do in the testcase that Kris pointed at)? Or maybe more realistically,
> > what about code segments generated dynamically by the process (like in
> > the case of a just in time, hotspot, compiler)?
> >   
> 
> They may or may not be there in the hot-spot case. If the segment has 
> been written to, though, it will be included as it cannot be recreated 
> post core dump.

OK, and I assume the same would be true for any code segments that were
altered through ptrace poke?

> > And from your explanation I now understand that you shouldn't
> > do it this way (need to audit the code a bit more to find all cases
> > where this happens), but go through the getMaps() interface and create a
> > Dwfl from that.
> >   
> Right, and I've talked a bit about this and learned that we should have 
> done core files right from that start. Right now (or rather we had) code 
> that makes assumptions that a process is alive and has entries in proc. 
> As I find them, I correct them, or ask the author to correct them. The 
> golden rule here is all information should always come from the Proc or 
> the Task. In the case of maps, it should be getMaps(). In the case of 
> memory, it should be via the Task's memory interface and so on.

Thanks. I filed bug #4852 to clean up the code where I abused it and
will go through the other stuff in the core listed there that uses the
wrong approach (I know I just copied what I did from some other existing
example, so it is good to get this fully cleaned up).

> Hope that helps!

It helped greatly. Thanks for sharing. Some of the things you said
suddenly made me see the bigger picture and connect the dots.

Cheers,

Mark