I'll step up, since I wrote gcore. I like what you're doing,
but I'm uncertain about the SOLIB_ADD part. Like you, I don't
understand why it was the way it was, nor the implications of
the change. But I think this can be done fairly easily without
that change.
Ok. I would sure like to know why core files work differently this way.
It would be nice if there were any comments in the code, for example!
The comment above update_solib_list says it's used for core files and
attaching, which is true. But it says nothing about why. I don't
understand why anything about this part of the solib handling would be
different for core files than for running.
Does this (rewriting your main loop using ALL_OBJSECTIONS)
seem reasonable?
Sure does. I didn't read enough code to understand exactly what
objfile_find_memory_regions was doing and misread it as doing less.
Along the way I noticed another difference between gcore-produced and
kernel-produced core dumps. The omitted segments in real core dumps
have nonzero p_memsz but zero p_filesz, which in phdrs indicates that
the memory is occupied but the contents are not available. gcore's
dumps zero the size, which gives a wrong indication of the address space.
I changed that as well, so gcore's dumps now look more like real dumps.
This works well enough. However, I think that making the determination
based on the kernel-supplied indication of anonymous vs file-backed may
make more sense. (Linux 2.6's behavior may be changing in this regard,
and using that as a determining factor rather than just permission
bits.) That would require changing the to_find_memory_regions interface
as I described earlier. Can you comment on that?