[patch x64 bfd]: Rework dump of pdata/xdata for x64

[Kai Tietz]

2010/9/15 Richard Henderson <rth@redhat.com>:
> On 09/15/2010 08:17 AM, Kai Tietz wrote:
>> +       fprintf (file, "  has %s begin address as antecessor\n",
>
> predecessor
>
>> +       fprintf (file, "  has negate begin address\n");
>
> negative
>
>> +static bfd_vma
>> +find_next_xdata_or_end (bfd *abfd, bfd_byte *pdata, bfd_size_type stop,
>> +                     int onaline, bfd_vma cur_address, bfd_vma max_size)
>
> I do wonder if a linear search is the right thing here.
>
> What about something like
>
>  N = number of pdata entries;
>  A = new rva[N + 1];
>
>  for (i = 0; i < N; i++)
>    A[i] = pdata[i].xdata_rva;
>  A[N] = xdata_end;
>
>  sort(A);
>
>  rva find_next_xdata(rva user_data)
>  {
>    Binary search for user_data in A.
>    If there is an exact match, the user_data
>    section is empty.  Otherwise, the end of
>    the user_data is the next highest value.
>  }
>
> I'm ok with this being done as a follow-on patch.

Yeah, you right, if we get here huge list it results in a N^2 behavior
over all elements.
I'll do that in a follow up patch by bsearch.

Patch adjusted. Ok for apply?

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x64_dump.diff
Type: application/octet-stream
Size: 8997 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20100915/e6f10e4a/attachment.obj>