Re: [PATCH] make gcore dump read-only sections not from files

[Michael Snyder <msnyder@redhat.com>]

Roland McGrath wrote:
>>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?

I'll go back and look, but meanwhile, this change is approved.

Michael