This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Target-specific FDE pointer sizes (3/3)
- From: Richard Sandiford <rsandifo at redhat dot com>
- To: binutils at sources dot redhat dot com
- Date: Sat, 29 Jan 2005 09:58:38 +0000
- Subject: Target-specific FDE pointer sizes (3/3)
- References: <874qh038y1.fsf@redhat.com> <87zmys1szw.fsf@redhat.com>
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