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

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

[Loren James Rittle]

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

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

[Richard Henderson]

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.

> 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

It is not required until

  (1) The OS implements dl_iterate_phdr or some equivalent functionality,
  (2) unwind-dw2-fde.c is suitably modified (a-la unwind-dw2-fde-glibc)
      to use (1).

> (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.)

*shrug*  I suppose Jakub was trying to save a bit of space in
the binary for those systems that never use the eh-frame-hdr.

> (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.

> 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.  ;-)


r~

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

[Loren James Rittle]

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

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

[Richard Henderson]

On Fri, Apr 26, 2002 at 01:44:25AM -0500, Loren James Rittle wrote:
> 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).

Trick question.  Mr Optimization isn't supposed to be running
with ld -r.  And this probably explains why we havn't seen the
problem on linux -- libtool doesn't think libgcj needs staging
here for some reason.

> 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 don't know.  This is the second 2.12/2.11.late binutils bug
to show up in the last week or so.  This kind of thing is
positively awful to detect in configure.


r~

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

[Jakub Jelinek]

On Wed, Apr 24, 2002 at 01:09:42PM -0500, Loren James Rittle wrote:
> 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]

Just wondering, do you have
http://sources.redhat.com/ml/binutils/2002-04/msg00331.html
patch installed?
Without it, DW_EH_PE_pcrel|DW_EH_PE_indirect encoded personality in CIEs
may be wrong...

	Jakub

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

[Loren James Rittle]

In article <20020426092948.D32482@sunsite.ms.mff.cuni.cz> you write:
>On Wed, Apr 24, 2002 at 01:09:42PM -0500, Loren James Rittle wrote:
>> 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:

> Just wondering, do you have
> http://sources.redhat.com/ml/binutils/2002-04/msg00331.html
> patch installed?
> Without it, DW_EH_PE_pcrel|DW_EH_PE_indirect encoded personality in CIEs
> may be wrong...

Hello Jakub,

I can confirm that I didn't have that binutils patch.  Updating
binutils 2.12.X past your patch, I can confirm that it does indeed fix
the root problem I saw.  If you saw my followup analysis, I did
observe that the shared library was being incrementally built.  I have
verified that all encoded references in such a library are now
consistent.

Since we believe the configure test is too complex (having seen the
interesting test that RTH created for .hidden on sparc-*-*, I am
fairly scared ;-), I will merely update release notes for this
platform.  I have no idea how widespread this problem is/was; for some
reason libtool insists upon incrementally building libjava.so (to work
around perceived command line length limitations even though the
entire unbroken command line seems to run fine on this platform).

Thanks,
Loren
-- 
Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs
rittle@rsch.comm.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672

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

[Jakub Jelinek]

On Fri, Apr 26, 2002 at 05:48:33PM -0500, Loren James Rittle wrote:
> Since we believe the configure test is too complex (having seen the
> interesting test that RTH created for .hidden on sparc-*-*, I am
> fairly scared ;-), I will merely update release notes for this
> platform.  I have no idea how widespread this problem is/was; for some
> reason libtool insists upon incrementally building libjava.so (to work
> around perceived command line length limitations even though the
> entire unbroken command line seems to run fine on this platform).

Since I've commited the DW_EH_PE_aligned fix the same day, I think it is
enough to test for the DW_EH_PE_aligned fix, which is doable and just assume
that noone picks one of the 2 patches and leaves the second one out.
I'll work on this tomorrow.

	Jakub

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

[David O'Brien]

On Fri, Apr 26, 2002 at 09:29:48AM +0200, Jakub Jelinek wrote:
> Just wondering, do you have
> http://sources.redhat.com/ml/binutils/2002-04/msg00331.html
> patch installed?

Not in the base system.

> Without it, DW_EH_PE_pcrel|DW_EH_PE_indirect encoded personality in CIEs
> may be wrong...

Please help push for 2.12.1.  One should have been released a month ago
with as bad shape as 2.12.0 is in.

-- 
-- David  (obrien@FreeBSD.org)

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

[David O'Brien]

On Fri, Apr 26, 2002 at 06:52:08PM -0400, Jakub Jelinek wrote:
> Since I've commited the DW_EH_PE_aligned fix the same day, I think it is
> enough to test for the DW_EH_PE_aligned fix, which is doable and just assume
> that noone picks one of the 2 patches and leaves the second one out.
> I'll work on this tomorrow.

I think Binutils 2.12 before your patch should just be ignored.  I can
update the 2.12 in the FreeBSD 5.0 tree.  FreeBSD soon-to-be-4.6 still
has 2.11.2.  I do not think the number of people trying to build GCC with
binutils 2.12.0 is large enough to worry about.

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

[David O'Brien]

On Fri, Apr 26, 2002 at 05:48:33PM -0500, Loren James Rittle wrote:
> platform.  I have no idea how widespread this problem is/was; for some
> reason libtool insists upon incrementally building libjava.so (to work
> around perceived command line length limitations even though the
> entire unbroken command line seems to run fine on this platform).

Interested in making a libtool patch to stop doing that? :-)

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

[Alexandre Oliva]

On Apr 30, 2002, "David O'Brien" <obrien@FreeBSD.org> wrote:

> On Fri, Apr 26, 2002 at 05:48:33PM -0500, Loren James Rittle wrote:
>> platform.  I have no idea how widespread this problem is/was; for some
>> reason libtool insists upon incrementally building libjava.so (to work
>> around perceived command line length limitations even though the
>> entire unbroken command line seems to run fine on this platform).

> Interested in making a libtool patch to stop doing that? :-)

This would be trivial.  Libtool doesn't measure the exact command-line
length, just a power of two or so.  Since it can't know for sure how
much additional command-line space the compiler driver is going to
add, measuring the exact length is kind of pointless.  You can
override the measured value by setting lt_cv_sys_max_cmd_len in your
environment.  Look for this variable name in ltconfig for the gory
details.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer