Hi
On 02/04/2019 03:27, H.J. Lu wrote:
> On Tue, Apr 2, 2019 at 10:05 AM Richard Henderson <r...@twiddle.net> wrote:
>>
>> On 4/1/19 8:53 PM, Sudakshina Das wrote:
>>>> This could stand to use a comment, a moment's thinking about the sizes,
>>>> and to
>>>> use the existing asm output functions.
>>>>
>>>> /* PT_NOTE header: namesz, descsz, type.
>>>> namesz = 4 ("GNU\0")
>>>> descsz = 12 (see below)
>>> I was trying out these changes but the descsz of 12 gets rejected by
>>> readelf. It hits the following
>>>
>>> unsigned int size = is_32bit_elf ? 4 : 8;
>>>
>>> printf (_(" Properties: "));
>>>
>>> if (pnote->descsz < 8 || (pnote->descsz % size) != 0)
>>> {
>>> printf (_("<corrupt GNU_PROPERTY_TYPE, size = %#lx>\n"),
>>> pnote->descsz);
>>> return;
>>> }
>>
>> Hmm, interesting. The docs say that padding is not to be included in descsz
>> (gabi4.1, page 82). To my eye this is a bug in binutils, but perhaps we will
>> have to live with it.
>>
>> Nick, thoughts?
>
> descsz is wrong. From:
>
> https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI
>
> n_desc The note descriptor. The first n_descsz bytes in n_desc is the pro-
> gram property array.
>
> The program property array
> Each array element represents one program property with type, data
> size and data.
> In 64-bit objects, each element is an array of 8-byte integers in the
> format of the
> target processor. In 32-bit objects, each element is an array of
> 4-byte integers in
> the format of the target processor.
Thanks @HJ for clarifying that. I should have been more careful in
spotting the difference.
@Richard I will update my patch according to your suggestions but
keeping in mind decssz should be the size of the entire program property
array so 16 in this case.
Thanks
Sudi
>
>
