qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC][PATCH 08/14 v9] target-i386: Add API to write cpu


From: HATAYAMA Daisuke
Subject: Re: [Qemu-devel] [RFC][PATCH 08/14 v9] target-i386: Add API to write cpu status to core file
Date: Mon, 19 Mar 2012 10:09:22 +0900 ( )

From: Wen Congyang <address@hidden>
Subject: Re: [RFC][PATCH 08/14 v9] target-i386: Add API to write cpu status to 
core file
Date: Fri, 16 Mar 2012 14:50:06 +0800

> At 03/16/2012 09:48 AM, HATAYAMA Daisuke Wrote:
>> From: Wen Congyang <address@hidden>
>> Subject: [RFC][PATCH 08/14 v9] target-i386: Add API to write cpu status to 
>> core file
>> Date: Wed, 14 Mar 2012 10:09:26 +0800
>> 
>>> +    memset(note, 0, note_size);
>>> +    if (type == 0) {
>>> +        note32 = note;
>>> +        note32->n_namesz = cpu_to_le32(name_size);
>>> +        note32->n_descsz = cpu_to_le32(descsz);
>>> +        note32->n_type = 0;
>>> +    } else {
>>> +        note64 = note;
>>> +        note64->n_namesz = cpu_to_le32(name_size);
>>> +        note64->n_descsz = cpu_to_le32(descsz);
>>> +        note64->n_type = 0;
>>> +    }
>> 
>> Why not give new type for this note information an explicit name?
>> Like NT_QEMUCPUSTATE? There might be another type in the future. This
>> way there's also a merit that we can know all the existing notes
>> relevant to qemu dump by looking at the names in a header file.
> 
> Hmm, how to add a new type? Does someont manage this?
> 

Sorry. I overlooked this.

For the first question, just prepare a name like NT_QEMUCPUSTATE, and
put it in elf.h.

For the second question, we will use it, and someone that will finds
another information worth being note information in qemu would extends
note informaiton. At least, crash needs to use CPU state information,
and Jan says he wants to use this information in his gdb extension.

Also, you've introduced new name "QEMU". The same type on different
name has different meaning. So, in theory, you don't have to worry
about collision of the new type with something else; they belong to
differnet namespace.

But, in reality, looking at elfcore_grok_note() in gdb that reads note
information of corefile, it don't see "CORE" name explicitly. It
regards everything as the one in "CORE" name if it doesn't belong to
any namespace other than "CORE" name. But in "CORE" core namespace,
indexing starts from 1, NT_PRSTATUS; no type 0 in "CORE".

/* Values of note segment descriptor types for core files.  */

#define NT_PRSTATUS     1               /* Contains copy of prstatus struct */
#define NT_FPREGSET     2               /* Contains copy of fpregset struct */
#define NT_PRPSINFO     3               /* Contains copy of prpsinfo struct */
#define NT_TASKSTRUCT   4               /* Contains copy of task struct */
#define NT_AUXV         6               /* Contains copy of Elfxx_auxv_t */
#define NT_PRXFPREG     0x46e62b7f      /* Contains a user_xfpregs_struct; */

It appears to me that type 0 is reserved in order to avoid confilicts.
So, you don't have to fix gdb for now as long as you introduce
NT_QEMUCPUSTATE only and index it with type 0.

Considering name "QEMU", QEMU in NT_QEMUCPUSTATE might be redundant.

Thanks.
HATAYAMA, Daisuke





reply via email to

[Prev in Thread] Current Thread [Next in Thread]