Re: Questions about ``[PATCH] GCC side of .eh_frame_hdr support (take 3)''

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <20020424112708.A1533@redhat.com>,
Richard Henderson <rth@redhat.com> writes:

> On Wed, Apr 24, 2002 at 01:09:42PM -0500, Loren James Rittle wrote:
>> Are these optimized EH frames readable by the unwinder in unwind-dw2-fde.c?

> Yes.  There is nothing unusual about these modified EH frames.
> We eliminated some duplicate information is all.

OK, makes perfect sense.

[...]
>> (I suspect so.)  Does this likely mask a binutils and/or gcc port bug
>> that should be tracked down?

> Likely a binutils bug.

>> The only difference I could detect with readelf(1) between GNU ld
>> 2.12.1 without --traditional-format and GNU ld 2.12.1 with
>> --traditional-format was the size of .eh_frame:

> Look at the output of readelf -wf.

This was fun; libjava is not a small library.  At least I know the
basic difference between a CIE and an FDE now. ;-)

Does this sound right:

libgcj built with --traditional-format contains 1209 CIEs and 9805
FDEs (readelf -wf output for .eh_frame only in "good").  libgcj built
without --traditional-format contains 252 CIEs and 9805 FDEs (readelf
-wf output for .eh_frame only in "bad").  I see every FDE has a link
back to a CIE so I wrote a quick awk script to double-check the links.

$ awk <good '$4 == "CIE" {seen["cie=" $1] = 1} \
             $4 == "FDE" {if (seen[$5] != 1) print "bad FDE"}'
$ awk <bad '$4 == "CIE" {seen["cie=" $1] = 1} \
            $4 == "FDE" {if (seen[$5] != 1) print "bad FDE"}'

No such obvious problem.  Next, given that I see a bogus personality
routine (after an otherwise proper unwind), I decided to write a
similar program to double-check the relative pointer encoded in CIE
Augmentation data. (This hack is not general.)

bash-2.04$ (echo 'obase=16'; echo 'ibase=16'; (awk <good  '$4 == "CIE" {offset=$1} $1 == "Augmentation" && $2 == "data:" && $3 == "9b" && $8 == "1b" {extra= 0; if ($9 == "1b") extra=1; print $7 $6 $5 $4, "+", offset, "+", extra}'|tr 'abcdef' 'ABCDEF'))|bc -l|uniq -c
1204 FFFF75BA

[The remaining 5 CIEs have no personality to speak of.]

Thus, I conclude all relative values are encoded consistently.  Since
the same personality routine is referenced in all cases, this looks OK.

Humm, I'm no expert in this area; but something does look amiss with
the optimized CIEs:

bash-2.04$ (echo 'obase=16'; echo 'ibase=16'; (awk <bad  '$4 == "CIE" {offset=$1} $1 == "Augmentation" && $2 == "data:" && $3 == "9b" && $8 == "1b" {extra= 0; if ($9 == "1b") extra=1; print $7 $6 $5 $4, "+", offset, "+", extra}'|tr 'abcdef' 'ABCDEF'))|bc -l
FFFF75BA
FFFF759A
FFFF759A
FFFF759A
FFFF757E
FFFF757E
FFFF74F2
FFFF74F2
FFFF74D6
FFFF747A
FFFF7116
[... total of 250 numbers in this truncated, decreasing list ...]
FFFF0CA6
FFFF0C6E
FFFF0BEE
FFFF0BEE
FFFF0BAE
FFFF0B76
FFFF0B76

When a CIE is moved within .eh_frame, does this encoded relative
reference need to be updated?  I can see that none of the encoded
Augmentation data is changed.  Thus, it appears relative references
were resolved before this optimization.  How could this happen?  One
interesting fact that might be related, libgcj.so is built by libtool
in three stages (I had assumed everywhere but perhaps only on some
platforms).

In stage one:

[...]/ld -r -o .libs/libgcj.la-1.o [long list of objects]

In stage two:

[...]/ld -r -o .libs/libgcj.la-2.o [long list of objects] .libs/libgcj.la-1.o

In stage three:

[...]/gcc/xgcc [...] .libs/libgcj.la-2.o [...] -o .libs/libgcj.so.3

When I manually rerun the step to create .libs/libgcj.la-2.o; I see
that the relative references encoded in Augmentation data have not
been resolved yet.  Thus, looks good.

However, guess what?  If I create libgcj.so.3 with one call to the
linker without --traditional-format (i.e. run only stage three by
replacing .libs/libgcj.la-2.o with the full list of files used in
stage one and two) and then produce readelf -wf output for .eh_frame
only in "ugly".

bash-2.04$ (echo 'obase=16'; echo 'ibase=16'; (awk <ugly  '$4 == "CIE" {offset=$1} $1 == "Augmentation" && $2 == "data:" && $3 == "9b" && $8 == "1b" {extra= 0; if ($9 == "1b") extra=1; print $7 $6 $5 $4, "+", offset, "+", extra}'|tr 'abcdef' 'ABCDEF'))|bc -l|uniq -c
 250 FFF2A1AA

I admit that I haven't debugged it back in binutils yet, but I think
that Mr. Optimization doesn't work with pre-staged relocatable output
(at least as created by libtool).  Given the time to a gcc 3.1
release, what is the best work around to this issue?  Does the answer
change knowing we have buggy binutils in the field?

I am willing to add --traditional-format to FreeBSD's linker spec
whenever it finds an ld with the optimization; if you think it is the
best course of action.  However, I believe this can affect other ports.

>> Trick question: What does --traditional-format mean to GNU ld 2.12.1
>> when it *is* the native linker for the system? ;-)

> Don't fiddle with the bits.  ;-)

Yes, given the man page, one would think so. ;-)

Regards,
Loren