This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Target-specific FDE pointer sizes (3/3)


Although the address size problem mentioned in the previous posts:

    http://sources.redhat.com/ml/binutils/2005-01/msg00504.html
    http://sources.redhat.com/ml/binutils/2005-01/msg00505.html

was a latent bug it only seems to have caused problems after my
recent padding optimisation:

    http://sources.redhat.com/ml/binutils/2005-01/msg00135.html

The idea is that we shrink this_inf->size to remove any padding:

      /* Try to interpret the CFA instructions and find the first
         padding nop.  Shrink this_inf's size so that it doesn't
         including the padding.  */
      length = get_DW_EH_PE_width (cie.fde_encoding, ptr_size);
      insns = skip_non_nops (insns, end, length);
      if (insns != 0)
        this_inf->size -= end - insns;

and then round it up to the required alignment boundary in
size_of_output_cie_fde:

  return (entry->size
          + extra_augmentation_string_bytes (entry)
          + extra_augmentation_data_bytes (entry)
          + alignment - 1) & -alignment;

This should be correct in theory, but it only works if we've got the
right value of "alignment" (the number of bytes in a pointer).  I wonder
if there are other targets for which we underestimate the pointer size,
and for which we might therefore end up with misaligned sizes?

If this worries anyone, the size shrinking code could be guarded with
something like:

        if (size_of_output_cie_fde (this_inf, ptr_size) > this_inf->size)

so that it only triggers when growing the entry.  A bit of defensive
programming, if you like.

My preference would be not to do this.  I think it's just another
case of "garbage in, garbage out", and I think we could still lose
in other ways if we've got the wrong address size.  Stiil, I thought
I'd better mention it, and I'm certainly happy to make the change if
there's demand.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]