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>]

While investigating the systematic libjava EH failure seen with GNU ld
2.12.1 (prerelease) but not 2.11.2 on i386-*-freebsd4.5, I stumbled
upon this interesting thread:

http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01552.html
http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01515.html

[Probably related: http://gcc.gnu.org/ml/gcc/2002-02/msg01424.html]

In particular (taken from above):

>>> If not, ld could do the .eh_frame optimizations unconditionally (provided it
>>> understands it) and --eh-frame-hdr could only request .eh_frame_hdr
>>> creation.
>> Yes, with the optimizations suppressed by --traditional-format.
> Done (in binutils CVS now).

Let's say I have GNU ld (2.12.1 prerelease) installed which causes
HAVE_LD_EH_FRAME_HDR to be defined to 1 while configuring gcc.  Based
upon reading the above only (in its full context), I take it that the
port is now getting some EH frame optimizations unless I explicitly
add --traditional-format.  Are these optimized EH frames readable by
the unwinder in unwind-dw2-fde.c ?  I assume the answer must be yes (or
is suppose to be yes), or they wouldn't have been enabled unconditionally.

[Next question based on explicit statement made in
 http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01383.html which was the
 first version of the patch that went into gcc concurrently with
 binutils support.]

Do I need to add this to the port's configuration file for any port
that might someday use GNU ld 2.12+? (Based on comment in alpha/elf.h,
I suspect it is not strictly required when unwind-dw2-fde.c is used by
a port.)

#if defined(HAVE_LD_EH_FRAME_HDR)
#define LINK_EH_SPEC "%{!static:--eh-frame-hdr} "
#endif

(I should not ask the obvious question: Why is something which depends
 solely upon the GNU ld version being added on a per-port basis?
 Perhaps adding it to config/elfos.h would have been wiser.  Oh well.)

Now, for the final kicker.  My interest was perked by the mention that
this new optimization could be disabled.  When I force libgcj.so to be
built with GNU ld 2.12.1 --traditional-format, the systematic libjava
EH failure completely vanishes.  Final question: Did I just get lucky?
(I suspect so.)  Does this likely mask a binutils and/or gcc port bug
that should be tracked down?  If so, any hint as to what the bug might
be?  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:

(diff ignoring fields $4 and $5)
< [18] .eh_frame         PROGBITS        004ff428 4fe428 11a468 00  WA  0   0  4
> [18] .eh_frame         PROGBITS        004ff428 4fe428 120ef4 00  WA  0   0  4

The root symptom I see is a bad value for the libjava EH personality
routine during phase 1 of the unwinding and that there were fewer
calls to extract_cie_info() with the (badly?) optimized libgcj.so.
The number of unwind region registrations is the same in both cases.
The C++ EH personality routine gets loaded properly when looking at
examples against libstdc++.so built with the same GNU ld.  I have
spent hours trying to read up on this stuff and the code; I fear that
I'm near wit's end on this problem.

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

Regards,
Loren