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

Michael Snyder
2003-10-09T21:55:37Z

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