Hi Phil,

On Thu, 2007-07-26 at 10:34 -0500, Phil Muldoon wrote:
> When a core file is modeled in Frysk, it could be a long time from when 
> the core was created. An executable file might not be even available at 
> that time. For this reason there are two layers of meta data built:
> 
> 1) Basic meta-data. No executable available. No maps can be produced 
> (but address ranges can). No solib tables can be built. No elided 
> segment memory access. At this point we can model the information that 
> is in the core file, and allow access to non-elided sections of the core 
> file. This is basic inspection. Can't do much other than look at memory, 
> and registers.

What does "elided" mean in this context?

> 2) Enhanced meta-data. Executable is available. In this case we can find 
> where the link-map was in the core file when it was dumped by looking at 
> the executable's dynamic segment. We can build a table of what solibs 
> were loaded and mapped into the process when it was dumped, and we can 
> build a "rich" set of maps  almost identical to what you would get in 
> /proc/$$/maps. We can now allow elided memory access because we know 
> what solib is at which address, so the host can open that solib and read 
> that memory. This allows sophisticated operations as stack back traces, 
> and so on.

OK, so does this mean not all code segments might be available in the
core elf file itself, but that you need to cross-reference them always
against the actual executable (but you aren't guaranteed access to the
orgininal executable since even the core file itself doesn't have a
reliable link to it)?

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)?

Finally, how does the rest of the core get access to these code
segments? For example in this testcase or in the DebugInfo, access to
the Elf object for the Proc is obtained by doing new Elf(proc.getExe()).
But since for core Procs that would give the (possible not full, or no
longer existing) path to the original executable that seems the wrong
approach. 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.

> Hope that sheds a bit of light.

Yes, thanks!

Mark