Re: fcore status

[Yong Zheng <zhengyo at cn dot ibm dot com>]

On Sun, 2006-10-15 at 16:47 -0500, Phil Muldoon wrote: 
> I've updated FCore and relevant sections of the Java elf bindings as shown by the Changelog entries below.
> 
> FCore utility class core files now have a complete elf header, program segment header, section string table, section and corresponding data. It does not have Notes yet, that's for the coming week. So  "basic" core files can be produced. There are buckets of caveats/bugs, but will get to those later.
> 
Phil, I notice one issue. In gdb, one map whose is unwritable won't be
dumped out by gcore. However, in our fcore, it is dumped out. I'm not
sure whether we should rethink of this. 

On one hand, if one map unwritable is dumped out, it will make the core
file larger. In gdb, it consider the map unwritable can be got from the
executable program in disk, which is the reason why gcore doesn't dump
out such kind of maps. For some application with large size, this will
dump out a large core file! 

On the other hand, if we dump out all entries in /proc/self/maps, we
maybe do more things on core file debugging than that gdb can do(now, we
must use gdb like this for core file debugging: gdb executable-file
core-file. And under such a circumstance we can't input step/next
commands. If we dump all, we maybe provide support for running step/next
commands in core file debugging. But it's just maybe.)

So what should we choose, dump out one map unwritable or not?

> Caveats:
> 
> - MapsBuilder seems to sometimes not produce complete map tables from /proc/$$/map

Some items in maps table are filtered out! Those items who are unreadable won't be built, such as 
[vdso] item in /proc/self/maps. So sometimes you will get one uncomplete map tables. But this doesn't matter.

> - I suspect as mixing ints (byte[] arrays size) with long (MapsBuilder api), with ints (inua.eio.ByteBuffer get parameters), we will smash on huge core files.
If you can detail this, it's very appreciated!

> - Task.getMemory() only seems to map up the maximum for 32 bit architectures?
I also notice this. But in PtraceByteBuffer.cxx, there's some comments about "maxOffset". The maxOffset isnot
checked in ByteBuffer interface. So it won't bring trouble to us now. 

Phil, we should add some new class for arch-dependent operations on ELF header and PT_NOTE dumping out. I hope I can post one
patches and have some discussion based on it.

Best regards
Yong Zheng