* Questions about ``[PATCH] GCC side of .eh_frame_hdr support (take 3)''
@ 2002-04-24 11:27 Loren James Rittle
2002-04-24 14:34 ` Richard Henderson
2002-04-26 1:55 ` Jakub Jelinek
0 siblings, 2 replies; 11+ messages in thread
From: Loren James Rittle @ 2002-04-24 11:27 UTC (permalink / raw)
To: gcc; +Cc: java
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Questions about ``[PATCH] GCC side of .eh_frame_hdr support (take 3)''
2002-04-24 11:27 Questions about ``[PATCH] GCC side of .eh_frame_hdr support (take 3)'' Loren James Rittle
@ 2002-04-24 14:34 ` Richard Henderson
2002-04-26 0:00 ` Loren James Rittle
2002-04-26 1:55 ` Jakub Jelinek
1 sibling, 1 reply; 11+ messages in thread
From: Richard Henderson @ 2002-04-24 14:34 UTC (permalink / raw)
To: rittle; +Cc: gcc, java
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~
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Questions about ``[PATCH] GCC side of .eh_frame_hdr support (take 3)''
2002-04-24 14:34 ` Richard Henderson
@ 2002-04-26 0:00 ` Loren James Rittle
2002-04-26 0:09 ` Richard Henderson
0 siblings, 1 reply; 11+ messages in thread
From: Loren James Rittle @ 2002-04-26 0:00 UTC (permalink / raw)
To: rth; +Cc: gcc, java
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Questions about ``[PATCH] GCC side of .eh_frame_hdr support (take 3)''
2002-04-26 0:00 ` Loren James Rittle
@ 2002-04-26 0:09 ` Richard Henderson
0 siblings, 0 replies; 11+ messages in thread
From: Richard Henderson @ 2002-04-26 0:09 UTC (permalink / raw)
To: rittle; +Cc: gcc, java
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~
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Questions about ``[PATCH] GCC side of .eh_frame_hdr support (take 3)''
2002-04-24 11:27 Questions about ``[PATCH] GCC side of .eh_frame_hdr support (take 3)'' Loren James Rittle
2002-04-24 14:34 ` Richard Henderson
@ 2002-04-26 1:55 ` Jakub Jelinek
2002-04-26 15:52 ` Loren James Rittle
2002-04-30 13:41 ` David O'Brien
1 sibling, 2 replies; 11+ messages in thread
From: Jakub Jelinek @ 2002-04-26 1:55 UTC (permalink / raw)
To: rittle; +Cc: gcc, java
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Questions about ``[PATCH] GCC side of .eh_frame_hdr support (take 3)''
2002-04-26 1:55 ` Jakub Jelinek
@ 2002-04-26 15:52 ` Loren James Rittle
2002-04-26 18:08 ` Jakub Jelinek
2002-04-30 14:10 ` David O'Brien
2002-04-30 13:41 ` David O'Brien
1 sibling, 2 replies; 11+ messages in thread
From: Loren James Rittle @ 2002-04-26 15:52 UTC (permalink / raw)
To: jakub; +Cc: java, gcc
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Questions about ``[PATCH] GCC side of .eh_frame_hdr support (take 3)''
2002-04-26 15:52 ` Loren James Rittle
@ 2002-04-26 18:08 ` Jakub Jelinek
2002-04-30 13:41 ` David O'Brien
2002-04-30 14:10 ` David O'Brien
1 sibling, 1 reply; 11+ messages in thread
From: Jakub Jelinek @ 2002-04-26 18:08 UTC (permalink / raw)
To: Loren James Rittle; +Cc: java, gcc
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Questions about ``[PATCH] GCC side of .eh_frame_hdr support (take 3)''
2002-04-26 1:55 ` Jakub Jelinek
2002-04-26 15:52 ` Loren James Rittle
@ 2002-04-30 13:41 ` David O'Brien
1 sibling, 0 replies; 11+ messages in thread
From: David O'Brien @ 2002-04-30 13:41 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: rittle, gcc, java
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)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Questions about ``[PATCH] GCC side of .eh_frame_hdr support (take 3)''
2002-04-26 18:08 ` Jakub Jelinek
@ 2002-04-30 13:41 ` David O'Brien
0 siblings, 0 replies; 11+ messages in thread
From: David O'Brien @ 2002-04-30 13:41 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Loren James Rittle, java, gcc
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Questions about ``[PATCH] GCC side of .eh_frame_hdr support (take 3)''
2002-04-26 15:52 ` Loren James Rittle
2002-04-26 18:08 ` Jakub Jelinek
@ 2002-04-30 14:10 ` David O'Brien
2002-05-05 0:40 ` Alexandre Oliva
1 sibling, 1 reply; 11+ messages in thread
From: David O'Brien @ 2002-04-30 14:10 UTC (permalink / raw)
To: Loren James Rittle; +Cc: jakub, java, gcc
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? :-)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Questions about ``[PATCH] GCC side of .eh_frame_hdr support (take 3)''
2002-04-30 14:10 ` David O'Brien
@ 2002-05-05 0:40 ` Alexandre Oliva
0 siblings, 0 replies; 11+ messages in thread
From: Alexandre Oliva @ 2002-05-05 0:40 UTC (permalink / raw)
To: obrien; +Cc: Loren James Rittle, jakub, java, gcc
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2002-05-05 7:40 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-04-24 11:27 Questions about ``[PATCH] GCC side of .eh_frame_hdr support (take 3)'' Loren James Rittle
2002-04-24 14:34 ` Richard Henderson
2002-04-26 0:00 ` Loren James Rittle
2002-04-26 0:09 ` Richard Henderson
2002-04-26 1:55 ` Jakub Jelinek
2002-04-26 15:52 ` Loren James Rittle
2002-04-26 18:08 ` Jakub Jelinek
2002-04-30 13:41 ` David O'Brien
2002-04-30 14:10 ` David O'Brien
2002-05-05 0:40 ` Alexandre Oliva
2002-04-30 13:41 ` David O'Brien
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).