Re: [PATCH][RFC] dump-core: PFN-GMFN table and ELF formatify (was Re: [Xen-devel] xc_get_pfn_list() creates broken core files)

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

On Wed, Jan 17, 2007 at 03:59:28AM +0000, John Levon wrote:
> On Mon, Jan 15, 2007 at 06:16:47PM +0900, Isaku Yamahata wrote:
> 
> > I added PFN-GMFN table to xen dump format and made it ELF format
> > based on John's patch. This patch isn't complete yet.
> 
> You use LINUX for the OSABI, which doesn't seem right.

Do you have any other correct value?
e.g. ELFOSABI_NONE (= ELFOSABI_SYSV = 0)
Or should it be compile-time configurable by defining something
like ELF_OSABI?


> I'm not clear why these are all program headers instead of sections.
> Given the slightly odd nature of this file, I would expect it to have no
> phdrs, or at most one phdr for the page array (and plus a section
> header). Same goes for notes - those would seem more useful as a
> section per type of thing (e.g. a .XEN_vcpu_context section, etc.). And
> that way you get the "what is this section's size" and "how big are the
> entries" for free.

I followed the way creating process core file and linux kernel dump file.
Process core file and linux kernel dump file use only program headers.
They use note section pointed by a program header to store register
infomations and etc.

Creating sections requires string table to store section name.
It makes dump-core code more compilated.
If using sections is appropreate for dump-core, such compilcations
might be acceptable.
However I don't see why section is more appropreate than program
header because I don't expect to have so many kind of notes.
At least for dump-core.

-- 
yamahata

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel