This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: eh-frame: CIE initial_instructions overflow
- From: Christophe Lyon <christophe dot lyon at linaro dot org>
- To: nick clifton <nickc at redhat dot com>
- Cc: binutils at sourceware dot org
- Date: Thu, 19 Dec 2013 16:46:32 +0100
- Subject: Re: eh-frame: CIE initial_instructions overflow
- Authentication-results: sourceware.org; auth=none
- References: <CAKdteOa8FJo=zw33AJ_waUMeOWviTO9bU2GYbsESSSR9mPf76Q at mail dot gmail dot com> <52B2D925 dot 5090103 at redhat dot com>
On 19 December 2013 12:31, nick clifton <nickc@redhat.com> wrote:
> Hi Christophe,
>
>
>> Currently, in bfd/elf-eh-frame.c we have a definition of struct cie
>> which ends with:
>> unsigned char initial_instructions[50];
>
>
> This is a bug...
>
>
>> In _bfd_elf_parse_eh_frame(), we have:
>> initial_insn_length = end - buf;
>> if (initial_insn_length <= sizeof (cie->initial_instructions))
>> {
>> cie->initial_insn_length = initial_insn_length;
>> memcpy (cie->initial_instructions, buf, initial_insn_length);
>> }
>
>
> IMHO - there should be no fixed size for the initial_instructions buffer.
> Instead the code at this point should allocate and copy the buffer that has
> just been created.
>
That's my feeling too, but I asked because this is going to be a
rather intrusive change: the surrounding code allocates an array of
CIE after having counted them.
Having a dynamic size here means we have to parse all the CIEs once to
get the biggest size, then allocate local_cies accordingly, then
reparse the section contents.
Not sure how costly it is to parse CIEs in general? Is there a risk to
increase link times significantly ?
Christophe.