C++ Issue on GCC 3.0 branch
Jeffrey A Law
A few of the remaining failures for PA32 using static libraries are
multiply defined symbols -- in each case one or more symbols defined by
the main program is a duplicate of a symbol in libstdc++.
For example, compiling g++.law/cvt2.C results in about a dozen duplicate
symbols (output has been massaged to be easier to read).
"std::istream::~istream()" in files cvt.o and libstdc++.a (misc-inst.o)
Similarly for the following symbols:
"std::basic_ios<char, std::char_traits<char> >::~basic_ios()"
"std::basic_ifstream<char, std::char_traits<char> >::~basic_ifstream()"
"std::basic_ios<char, std::char_traits<char> >::~basic_ios()"
"std::basic_ifstream<char, std::char_traits<char> >::basic_ifstream(char
const*, std::_Ios_Openmode)"
[ ... ]
I'm not enough of a C++ guru to know where to start with this one, so any
help y'all could provide would be greatly appreciated.
jeff
John David Anglin
> multiply defined symbols -- in each case one or more symbols defined by
> the main program is a duplicate of a symbol in libstdc++.
The duplicate symbol problem also prevents building a shared libstdc++.,
particularly if you use a low optimization level for debugging.
I have been trying to track this for a couple of days. The enclosed
patch may resolve the problem of duplicate symbols. It appears to prevent
the symbols from being exported. However, I have no idea whether it is
technically correct. It is possible the problem should be fixed when
the original clone decl is created.
The functions are all constructors being instantiated from templates.
It is my assumption that these don't really need to be accessible from
other files and the duplication won't be a problem (ie., static data
should be in common). On systems with weak support, they are weak
symbols.
The patch is not a complete solution. There are still import assembler
statements being generated for these functions. I have being trying to
figure out how DECL_EXTERNAL gets set but so far I can't find where it
is set. I tried setting breaks on every place that cc1plus sets it
directly but this didn't work. I am now running a test using `watch'
but this is incredibly slow.
Dave
--
J. David Anglin dave....@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
2001-04-21 John David Anglin <da...@hiauly1.hia.nrc.ca>
* optimize.c (maybe_clone_body): Copy TREE_PUBLIC to clone.
--- optimize.c.orig Wed Apr 11 15:05:20 2001
+++ optimize.c Fri Apr 20 16:14:38 2001
@@ -1028,6 +1028,7 @@
int parmno;
/* Update CLONE's source position information to match FN's. */
+ TREE_PUBLIC (clone) = TREE_PUBLIC (fn);
DECL_SOURCE_FILE (clone) = DECL_SOURCE_FILE (fn);
DECL_SOURCE_LINE (clone) = DECL_SOURCE_LINE (fn);
DECL_INLINE (clone) = DECL_INLINE (fn);
David Edelsohn
building libstdc++ shared library and tests. AIX does not consider it an
error by default and uses one instance.
David
Mark Mitchell
Dave --
Would you mind preparing a small testcase to demonstrate the
problem? (Compile this file, compile that file, note that they both
generate definitions of the same constructor.)
Then, mail them to me, with the PA traget-triplet and cc1plus
command-line options. I should be able to track down what's going on,
although someone may have to remind me about how some of the PA
assembler directives work...
Thanks to both you and Jeff for getting us this far. I think this a
case where I can probably step in to get us past this hurdle.
Thanks,
--
Mark Mitchell ma...@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
John David Anglin
Close but no cigar. This one actually bootstraps with no regressions under
i686 linux. However, I think it only addresses the symptom of the problem.
There must be a label uses problem somewhere. In any event, the testcase
for duplicate symbols will compile with the patch installed.
Dave
--
J. David Anglin dave....@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
2001-04-21 John David Anglin <da...@hiauly1.hia.nrc.ca>
* builtins.c (expand_builtin_setjmp): Mark next_lab as used.
--- builtins.c.orig Wed Feb 7 05:24:22 2001
+++ builtins.c Sat Apr 21 20:18:59 2001
@@ -617,6 +617,7 @@
buf_addr = expand_expr (TREE_VALUE (arglist), NULL_RTX, VOIDmode, 0);
next_lab = gen_label_rtx ();
+ LABEL_PRESERVE_P (next_lab) = 1;
cont_lab = gen_label_rtx ();
expand_builtin_setjmp_setup (buf_addr, next_lab);
Mark Mitchell
>> Then, mail them to me, with the PA traget-triplet and cc1plus
>> command-line options. I should be able to track down what's
>> going on, although someone may have to remind me about how some
>> of the PA assembler directives work...
John> I think I am beginning to see the light. In start_objects,
John> there is the code:
John> #if defined(ASM_OUTPUT_CONSTRUCTOR) &&
John> defined(ASM_OUTPUT_DESTRUCTOR) /* It can be a static
John> function as long as collect2 does not have to scan the
John> object file to find its ctor/dtor routine. */ TREE_PUBLIC
John> (current_function_decl) = 0; #endif
I'm sorry I haven't had more time to work on your problem this
weekend. I've been working on a proposal that I need to get out. I
will try to look at it more tonight, using your patch to cobble around
the cross-compilation abort.
I think this is a red herring though -- I think this code is talking
about "static constructors" which are the things that arrange for
global initialization and finalization, not constructors for
individual types, which is what the symbols you referenced were
talking about.
Yours,
John David Anglin
> about "static constructors" which are the things that arrange for
> global initialization and finalization, not constructors for
> individual types, which is what the symbols you referenced were
> talking about.
Can you point me to where the "model" for type constructors is set
up?
Regarding the constructors for global initialization, I think that
Jeff's patch truncating the length of section (subspace) names
needs to be reverted. I am getting a bunch of unresolved symbol
references from the dynamic loader involving global constructor
names that have been truncated.
I believe the core dump by HP nm doesn't occur with the "-p" option
even when the section names are longer than 31 characters. I will
know more soon if this is the case.
Bernd Schmidt
> > 2001-04-21 John David Anglin <da...@hiauly1.hia.nrc.ca>
> >
> > * builtins.c (expand_builtin_setjmp_setup): Set nonlocal flag in label.
>
> Close but no cigar. This one actually bootstraps with no regressions under
> i686 linux. However, I think it only addresses the symptom of the problem.
> There must be a label uses problem somewhere. In any event, the testcase
> for duplicate symbols will compile with the patch installed.
You might want to look at the patches I installed on the 2.95 branch after
2.95.3. This sounds like it's exactly the same problem.
Bernd
l...@redhat.com
> > I think this is a red herring though -- I think this code is talking
> > about "static constructors" which are the things that arrange for
> > global initialization and finalization, not constructors for
> > individual types, which is what the symbols you referenced were
> > talking about.
>
> Can you point me to where the "model" for type constructors is set
> up?
>
> Regarding the constructors for global initialization, I think that
> Jeff's patch truncating the length of section (subspace) names
> needs to be reverted. I am getting a bunch of unresolved symbol
> references from the dynamic loader involving global constructor
> names that have been truncated.
The whole purpose of the change is to not get false hits when collect2
search for ctors/dtors which lead to undefined symbols.
I'd rather not remove "-p" just because hpux's nm core dumps with the option
unless having the option gives us no benefit. I'm not likely revert the
truncation of section names, even if we remove -p. Once bitten, twice shy.
jeff
John David Anglin
> do not have ASM_OUTPUT_{CONSTRUCTOR,DESTRUCTOR} defined rather than look for
> a SOM specific solution.
I reverted the subspace name truncation in pa.h and did a build last night.
This resolved the problem with missing symbols that I saw. With this and
the constructor patch, the shared libstdc++ now builds. However, most
applications linked to it generate a segmentation fault when they start.
It appears this happens when they try to run the constructors. I will see if
I can figure out what's going wrong.
John David Anglin
> > Jeff's patch truncating the length of section (subspace) names
> > needs to be reverted. I am getting a bunch of unresolved symbol
> > references from the dynamic loader involving global constructor
> > names that have been truncated.
> This sounds like you haven't rebuilt collect2 after my change for NM_FLAGS.
No, collect was definitely rebuilt.
> The whole purpose of the change is to not get false hits when collect2
> search for ctors/dtors which lead to undefined symbols.
>
> I'd rather not remove "-p" just because hpux's nm core dumps with the option
> unless having the option gives us no benefit. I'm not likely revert the
> truncation of section names, even if we remove -p. Once bitten, twice shy.
The patch was to remove " -n", not "-p" from NM_FLAGS. HP nm doesn't dump
core on objects with long subspace names when "-p" is used. This allows
using the long subspace names again, although I would have prefered not to
because of the bug in HP nm. With "-p", the subspaces aren't output and
there are no false hits.
This is the change to the subspace output. It fixes various missing
global names. I don't fully understand the problem but I did see that
the missing constructors in the shared library had truncated names.
I use GNU nm rather than HP nm for my builds. Thus, there is no possibilty
for false hits.
Dave
--
J. David Anglin dave....@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
2001-04-22 John David Anglin <da...@hiauly1.hia.nrc.ca>
* som.h: Don't truncate subspace names.
--- som.h.save Sun Apr 22 15:18:51 2001
+++ som.h Sun Apr 22 19:32:15 2001
@@ -135,7 +135,7 @@
fputs ("\t.NSUBSPA $CODE$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY\n", FILE); \
else if (TARGET_GAS) \
fprintf (FILE, \
- "\t.SUBSPA .%.30s\n", name); \
+ "\t.SUBSPA .%s\n", name); \
}
#define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL) \
@@ -280,10 +280,10 @@
fputs ("\t.SPACE $TEXT$\n", FILE); \
if (TARGET_GAS) \
fprintf (FILE, \
- "\t.NSUBSPA %.31s,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY,SORT=24\n", NAME);\
+ "\t.NSUBSPA %s,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY,SORT=24\n", NAME);\
else \
fprintf (FILE, \
- "\t.NSUBSPA $%.29s$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY,SORT=24\n", NAME);\
+ "\t.NSUBSPA $%s$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY,SORT=24\n", NAME);\
} \
else if (!RELOC && DECL && DECL_READONLY_SECTION (DECL, RELOC))\
{ \
l...@redhat.com
com>you write:
> Just remembered; this also needs the followup
>
> 2001-03-30 Bernd Schmidt <ber...@redhat.com>
>
> * jump.c (delete_barrier_successors): Fix error in last change.
OK. Thanks. I'll give the set a whirl on my PAs :-)
jeff
l...@redhat.com
> > I'd like to see us look for a general solution for the set of targets whi
> ch
> > do not have ASM_OUTPUT_{CONSTRUCTOR,DESTRUCTOR} defined rather than look
> for
> > a SOM specific solution.
>
> I reverted the subspace name truncation in pa.h and did a build last night.
> This resolved the problem with missing symbols that I saw. With this and
> the constructor patch, the shared libstdc++ now builds. However, most
> applications linked to it generate a segmentation fault when they start.
> It appears this happens when they try to run the constructors. I will see
> if
> I can figure out what's going wrong.
jeff
Bernd Schmidt
> In message <Pine.LNX.4.33.01042...@host140.cambridge.redhat.
> com>you write:
> > > There must be a label uses problem somewhere. In any event, the testcase
> > > for duplicate symbols will compile with the patch installed.
> >
> > You might want to look at the patches I installed on the 2.95 branch after
> > 2.95.3. This sounds like it's exactly the same problem.
> Are you referring to this patch?
>
> 2001-03-28 Bernd Schmidt <ber...@redhat.com>
>
> * flow.c (propagate_block): When trying to delete a case vector, cope
> if its label has LABEL_PRESERVE_P set.
> * jump.c (jump_optimize_1): Move call to delete_barrier_successors to
> a point where JUMP_LABELS and LABEL_NUSES are set up properly.
> (delete_barrier_successors): If deleting a table jump, delete the case
> vector as well.
> * varasm.c (force_const_mem): If we have a label, set LABEL_PRESERVE_P
> so it won't get deleted.
Yes.
Bernd
Bernd Schmidt
Just remembered; this also needs the followup
2001-03-30 Bernd Schmidt <ber...@redhat.com>
* jump.c (delete_barrier_successors): Fix error in last change.
Bernd
John David Anglin
> > the constructor patch, the shared libstdc++ now builds. However, most
> > applications linked to it generate a segmentation fault when they start.
> > It appears this happens when they try to run the constructors. I will see
> > if
> > I can figure out what's going wrong.
> Please stop. You're going down the wrong direction into a rathole.
Don't think so but your entitled to your opinions. Note that the static
results for the libstdc++-v3 testsuite are still reasonable with my changes.
John David Anglin
> > This resolved the problem with missing symbols that I saw. With this and
> > the constructor patch, the shared libstdc++ now builds. However, most
> > applications linked to it generate a segmentation fault when they start.
> > It appears this happens when they try to run the constructors. I will see
> > if
> > I can figure out what's going wrong.
> Please stop. You're going down the wrong direction into a rathole.
Here is some more information about the above problem using:
# /usr/local/bin/hp735-hpux-gdb header_ciso646.sh-exe
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (hppa1.1-hp-hpux --target hp735-hpux),
Copyright 1996 Free Software Foundation, Inc...
(gdb) run
Starting program: /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/test
suite/header_ciso646.sh-exe
warning: Unable to find __d_pid symbol in object file.
warning: Suggest linking with /usr/lib/end.o.
warning: GDB will be unable to track shl_load/shl_unload calls
Current language: auto; currently c
Program received signal SIGSEGV, Segmentation fault.
0x7adfdc08 in _ZNSt8ios_base4InitC1Ev (this=0x7ada5998)
at ../../../../libstdc++-v3/src/ios.cc:138
138 if (++_S_ios_base_init == 1)
Current language: auto; currently c++
(gdb) bt
#0 0x7adfdc08 in _ZNSt8ios_base4InitC1Ev (this=0x7ada5998)
at ../../../../libstdc++-v3/src/ios.cc:138
#1 0x7adfae90 in _Z41__static_initialization_and_destruction_0ii (
__initialize_p=1, __priority=65535)
at ../../../../libstdc++-v3/include/bits/stl_algobase.h:57
#2 0x7adfb264 in _GLOBAL__I__ZNKSt12_Base_bitsetILj1EE16_M_do_find_firstEj ()
at ../../../../libstdc++-v3/include/bits/stl_algobase.h:727
#3 0x7ade43dc in _GLOBAL__FI_libstdc___sl_3_0 ()
#4 0x28a0 in __do_global_ctors ()
#5 0x2950 in __main ()
#6 0x4f20 in main ()
at /xxx/gnu/gcc-3.0/libstdc++-v3/testsuite/17_intro/header_ciso646.cc:122
The program binding has been changed to immediate. I am using the above
old version of gdb because gdb 5.0 (my latest build) dumps core when the
program hits the SIGSEGV.
(gdb) disass
Dump of assembler code for function _ZNSt8ios_base4InitC1Ev:
0x7adfdb58 <_ZNSt8ios_base4InitC1Ev>: stw rp,-14(sr0,sp)
0x7adfdb5c <_ZNSt8ios_base4InitC1Ev+4>: copy r3,r1
0x7adfdb60 <_ZNSt8ios_base4InitC1Ev+8>: copy sp,r3
0x7adfdb64 <_ZNSt8ios_base4InitC1Ev+12>: stwm r1,1c0(sr0,sp)
0x7adfdb68 <_ZNSt8ios_base4InitC1Ev+16>: stw r19,-20(sr0,sp)
0x7adfdb6c <_ZNSt8ios_base4InitC1Ev+20>: stw r18,c8(sr0,r3)
0x7adfdb70 <_ZNSt8ios_base4InitC1Ev+24>: stw r17,cc(sr0,r3)
0x7adfdb74 <_ZNSt8ios_base4InitC1Ev+28>: stw r16,d0(sr0,r3)
0x7adfdb78 <_ZNSt8ios_base4InitC1Ev+32>: stw r15,d4(sr0,r3)
0x7adfdb7c <_ZNSt8ios_base4InitC1Ev+36>: stw r14,d8(sr0,r3)
0x7adfdb80 <_ZNSt8ios_base4InitC1Ev+40>: stw r13,dc(sr0,r3)
0x7adfdb84 <_ZNSt8ios_base4InitC1Ev+44>: stw r12,e0(sr0,r3)
0x7adfdb88 <_ZNSt8ios_base4InitC1Ev+48>: stw r11,e4(sr0,r3)
0x7adfdb8c <_ZNSt8ios_base4InitC1Ev+52>: stw r10,e8(sr0,r3)
0x7adfdb90 <_ZNSt8ios_base4InitC1Ev+56>: stw r9,ec(sr0,r3)
0x7adfdb94 <_ZNSt8ios_base4InitC1Ev+60>: stw r8,f0(sr0,r3)
0x7adfdb98 <_ZNSt8ios_base4InitC1Ev+64>: stw r7,f4(sr0,r3)
0x7adfdb9c <_ZNSt8ios_base4InitC1Ev+68>: stw r6,f8(sr0,r3)
0x7adfdba0 <_ZNSt8ios_base4InitC1Ev+72>: stw r5,fc(sr0,r3)
0x7adfdba4 <_ZNSt8ios_base4InitC1Ev+76>: stw r4,100(sr0,r3)
0x7adfdba8 <_ZNSt8ios_base4InitC1Ev+80>: ldo 108(r3),r1
0x7adfdbac <_ZNSt8ios_base4InitC1Ev+84>: fstds,ma fr21,8(sr0,r1)
0x7adfdbb0 <_ZNSt8ios_base4InitC1Ev+88>: fstds,ma fr20,8(sr0,r1)
0x7adfdbb4 <_ZNSt8ios_base4InitC1Ev+92>: fstds,ma fr19,8(sr0,r1)
0x7adfdbb8 <_ZNSt8ios_base4InitC1Ev+96>: fstds,ma fr18,8(sr0,r1)
0x7adfdbbc <_ZNSt8ios_base4InitC1Ev+100>: fstds,ma fr17,8(sr0,r1)
0x7adfdbc0 <_ZNSt8ios_base4InitC1Ev+104>: fstds,ma fr16,8(sr0,r1)
0x7adfdbc4 <_ZNSt8ios_base4InitC1Ev+108>: fstds,ma fr15,8(sr0,r1)
0x7adfdbc8 <_ZNSt8ios_base4InitC1Ev+112>: fstds,ma fr14,8(sr0,r1)
0x7adfdbcc <_ZNSt8ios_base4InitC1Ev+116>: fstds,ma fr13,8(sr0,r1)
0x7adfdbd0 <_ZNSt8ios_base4InitC1Ev+120>: fstds,ma fr12,8(sr0,r1)
0x7adfdbd4 <_ZNSt8ios_base4InitC1Ev+124>: stw r26,-24(sr0,r3)
0x7adfdbd8 <_ZNSt8ios_base4InitC1Ev+128>:
bl 0x7adfdac8 <__get_eh_context>,rp
0x7adfdbdc <_ZNSt8ios_base4InitC1Ev+132>: nop
0x7adfdbe0 <_ZNSt8ios_base4InitC1Ev+136>: ldw 9c(sr0,r3),r19
0x7adfdbe4 <_ZNSt8ios_base4InitC1Ev+140>: copy ret0,r20
0x7adfdbe8 <_ZNSt8ios_base4InitC1Ev+144>: stws r20,-10(sr0,sp)
0x7adfdbec <_ZNSt8ios_base4InitC1Ev+148>: fldws -10(sr0,sp),fr22
0x7adfdbf0 <_ZNSt8ios_base4InitC1Ev+152>: fstws fr22,-10(sr0,sp)
0x7adfdbf4 <_ZNSt8ios_base4InitC1Ev+156>: ldws -10(sr0,sp),r1
0x7adfdbf8 <_ZNSt8ios_base4InitC1Ev+160>: stw r1,a4(sr0,r3)
0x7adfdbfc <_ZNSt8ios_base4InitC1Ev+164>: stw r19,9c(sr0,r3)
0x7adfdc00 <_ZNSt8ios_base4InitC1Ev+168>: addil -1000,r19
0x7adfdc04 <_ZNSt8ios_base4InitC1Ev+172>: copy r1,r21
0x7adfdc08 <_ZNSt8ios_base4InitC1Ev+176>: ldw 324(sr0,r21),r21
Register is wrong (it is 0 at 0x7adfdc00) causing the fault at the ldw.
Register r21 is 0xfffff000. This looks like a code problem.
John David Anglin
> 0x7adfdbd8 <_ZNSt8ios_base4InitC1Ev+128>:
> bl 0x7adfdac8 <__get_eh_context>,rp
> 0x7adfdbdc <_ZNSt8ios_base4InitC1Ev+132>: nop
> 0x7adfdbe0 <_ZNSt8ios_base4InitC1Ev+136>: ldw 9c(sr0,r3),r19
> 0x7adfdbe4 <_ZNSt8ios_base4InitC1Ev+140>: copy ret0,r20
> 0x7adfdbe8 <_ZNSt8ios_base4InitC1Ev+144>: stws r20,-10(sr0,sp)
> 0x7adfdbec <_ZNSt8ios_base4InitC1Ev+148>: fldws -10(sr0,sp),fr22
> 0x7adfdbf0 <_ZNSt8ios_base4InitC1Ev+152>: fstws fr22,-10(sr0,sp)
> 0x7adfdbf4 <_ZNSt8ios_base4InitC1Ev+156>: ldws -10(sr0,sp),r1
> 0x7adfdbf8 <_ZNSt8ios_base4InitC1Ev+160>: stw r1,a4(sr0,r3)
> 0x7adfdbfc <_ZNSt8ios_base4InitC1Ev+164>: stw r19,9c(sr0,r3)
The problem was not my patch. There is a real problem with pic C++ code.
The problem is that the "first" save for register r19 comes after the first
function call. The initial save of r19 was to meet ABI requirements. The
save at 0x7adfdbfc is the real save that was supposed to be used for
restoration of r19 after function calls.
You can see the problem in the rtl:
;; Function std::ios_base::Init::Init()
(note 1 0 6 ("../../../../libstdc++-v3/src/ios.cc") 137 0)
(insn 6 1 54 (set (reg/v/u/f:SI 94)
(reg:SI 26 %r26)) -1 (nil)
(expr_list:REG_EQUIV (mem/u/f:SI (plus:SI (reg/f:SI 89 virtual-incoming-args)
(const_int -4 [0xfffffffc])) 0)
(nil)))
(insn 54 6 43 (use:SI (reg:SI 105)) -1 (nil)
(expr_list:REG_EH_CONTEXT (reg:SI 105)
(nil)))
(insn 43 54 7 (set (reg:SI 103)
(reg:SI 19 %r19)) -1 (nil)
(nil))
(note 7 43 15 NOTE_INSN_FUNCTION_BEG 0)
(note 15 7 17 ("../../../../libstdc++-v3/src/ios.cc") 138 0)
As can be seen, the eh context stuff has been pushed to the beginning of
the function. We need insn 43 to be at the beginning before the eh
context stuff. We try to put the save at the start in hppa_init_pic_save:
void hppa_init_pic_save ()
{
rtx insn, picreg;
picreg = gen_rtx_REG (word_mode, PIC_OFFSET_TABLE_REGNUM);
PIC_OFFSET_TABLE_SAVE_RTX = gen_reg_rtx (Pmode);
insn = gen_rtx_SET (VOIDmode, PIC_OFFSET_TABLE_SAVE_RTX, picreg);
/* Emit the insn at the beginning of the function after the prologue. */
push_topmost_sequence ();
emit_insn_after (insn, last_parm_insn ? last_parm_insn : get_insns ());
pop_topmost_sequence ();
}
This is called when the first call insn is encountered. Any thoughts
on how to fix this?
l...@redhat.com
> As can be seen, the eh context stuff has been pushed to the beginning of
> the function. We need insn 43 to be at the beginning before the eh
> context stuff. We try to put the save at the start in hppa_init_pic_save:
So, if you've got time, you'd want to investigate precisely how the code to
call get_eh_context gets inserted before the code to save the PIC register.
jeff
John David Anglin
Yes! I think that I have the fix. See below.
The call to get_eh_context gets inserted before the code to save the PIC
register with the same technique that we use to save the PIC register:
rtx
get_eh_context ()
{
if (current_function_ehc == 0)
{
rtx insn;
current_function_ehc = gen_reg_rtx (Pmode);
insn = gen_rtx_USE (GET_MODE (current_function_ehc),
current_function_ehc);
insn = emit_insn_before (insn, get_first_nonparm_insn ());
REG_NOTES (insn)
= gen_rtx_EXPR_LIST (REG_EH_CONTEXT, current_function_ehc,
REG_NOTES (insn));
}
return current_function_ehc;
}
Here are my latest test results for libstdc++-v3:
(chmod + ./mkcheck; \
srcdir=`cd ../../../libstdc++-v3; pwd`; builddir=`pwd`; \
test -d testsuite || (mkdir testsuite; chmod u+w testsuite); \
cd testsuite; ${builddir}/mkcheck 0 ${builddir} ${srcdir})
running mkcheck
/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: testing the build directory
making utility ./printnow.exe
Detailed test results in ../20010424-mkcheck.txt
+: pass, -b: build failure, -r: run failure, x: disabled
------------------------------------------------------------------------
static shared test
------------------------------------------------------------------------
+ + 17_intro/header_ciso646.cc
+ + 17_intro/header_cstdio.cc
+ + 17_intro/header_cstdlib.cc
+ + 17_intro/header_cstring.cc
+ + 17_intro/header_ctime.cc
+ + 17_intro/header_cwchar.cc
+ + 17_intro/header_cwctype.cc
+ + 17_intro/header_fstream.cc
+ + 17_intro/header_iomanip.cc
+ + 17_intro/header_ios.cc
+ + 17_intro/header_iosfwd.cc
+ + 17_intro/header_iostream.cc
+ + 17_intro/header_istream.cc
+ + 17_intro/header_ostream.cc
+ + 17_intro/header_sstream.cc
+ + 17_intro/header_streambuf.cc
+ + 17_intro/headers.cc
+ + 17_intro/headers_c++.cc
+ + 17_intro/headers_c.cc
+ + 18_support/numeric_limits.cc
+ + 19_diagnostics/stdexceptions.cc
+ + 20_util/auto_ptr.cc
+ -r 21_strings/append.cc
-b -b 21_strings/capacity.cc
+ + 21_strings/char_traits_requirements.cc
+ + 21_strings/char_traits_typedefs.cc
+ + 21_strings/compare.cc
-r -r 21_strings/ctor_copy_dtor.cc
+ -r 21_strings/element_access.cc
+ + 21_strings/find.cc
+ -r 21_strings/insert.cc
+ + 21_strings/inserters_extractors.cc
+ + 21_strings/invariants.cc
+ + 21_strings/nonmember.cc
+ + 21_strings/operations.cc
+ + 21_strings/replace.cc
+ + 21_strings/rfind.cc
+ -r 21_strings/substr.cc
+ + 22_locale/codecvt_char_char.cc
+ + 22_locale/codecvt_unicode_char.cc
+ + 22_locale/codecvt_unicode_wchar_t.cc
+ + 22_locale/codecvt_wchar_t_char.cc
+ + 22_locale/ctor_copy_dtor.cc
+ + 22_locale/ctype.cc
-r /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: failed: invalid number
-r /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: failed: invalid number
22_locale/ctype_char_members.cc
+ + 22_locale/ctype_wchar_t_members.cc
+ + 22_locale/facet.cc
+ + 22_locale/global_templates.cc
+ + 22_locale/members.cc
-b -b 22_locale/numpunct.cc
+ + 22_locale/numpunct_byname.cc
+ + 22_locale/numpunct_char_members.cc
+ + 22_locale/operators.cc
+ + 22_locale/static_members.cc
+ + 23_containers/bitset_ctor.cc
+ + 23_containers/bitset_shift.cc
-b -b 23_containers/map_operators.cc
+ + 23_containers/multiset.cc
-b -b 23_containers/set_operators.cc
+ + 23_containers/vector_capacity.cc
+ + 23_containers/vector_ctor.cc
+ -r 23_containers/vector_element_access.cc
+ + 23_containers/vector_modifiers.cc
+ + 24_iterators/istreambuf_iterator.cc
+ + 24_iterators/iterator.cc
+ + 25_algorithms/equal.cc
+ + 25_algorithms/lower_bound.cc
+ + 25_algorithms/min_max.cc
+ /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: =: invalid number
+ /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: =: invalid number
26_numerics/binary_closure.cc
+ + 26_numerics/buggy_complex.cc
+ + 26_numerics/c99_macros.cc
+ + 26_numerics/c_math.cc
+ + 26_numerics/complex_inserters_extractors.cc
+ + 26_numerics/complex_value.cc
+ + 26_numerics/valarray.cc
-b -b 27_io/filebuf.cc
+ + 27_io/filebuf_members.cc
+ + 27_io/fpos.cc
+ + 27_io/ifstream_members.cc
+ + 27_io/ios_base_callbacks.cc
-r /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: 24689timemark: invalid number
-r /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: 24689timemark: invalid number
27_io/ios_base_members_static.cc
+ + 27_io/ios_base_storage.cc
+ + 27_io/ios_ctor.cc
+ + 27_io/ios_manip_basefield.cc
+ + 27_io/ios_manip_fmtflags.cc
+ -r 27_io/ios_members.cc
+ + 27_io/istream.cc
+ + 27_io/istream_extractor_arith.cc
-r /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: failed: invalid number
-r /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: failed: invalid number
27_io/istream_extractor_char.cc
+ + 27_io/istream_extractor_other.cc
+ + 27_io/istream_manip.cc
-b -b 27_io/istream_seeks.cc
+ + 27_io/istream_sentry.cc
diff: ./istream_unformatted-2.txt: No such file or directory
+ diff: ./istream_unformatted-2.txt: No such file or directory
+ 27_io/istream_unformatted.cc
+ + 27_io/istringstream_members.cc
+ /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: cout: invalid number
+ /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: cout: invalid number
27_io/narrow_stream_objects.cc
+ + 27_io/ofstream_members.cc
+ + 27_io/ostream.cc
+ + 27_io/ostream_inserter_arith.cc
+ + 27_io/ostream_inserter_char.cc
+ + 27_io/ostream_inserter_other.cc
+ + 27_io/ostream_manip.cc
+ + 27_io/ostream_seeks.cc
+ + 27_io/ostream_unformatted.cc
+ + 27_io/streambuf.cc
+ + 27_io/stringbuf.cc
+ + 27_io/stringstream.cc
+ + 27_io/wide_stream_objects.cc
+ + ext/headers.cc
testrun == 9137 seconds
Most of the shared test now run sucessfully! Yeah!
Here is the configuration:
1) Patch below to add the pic save to the parameter insns.
2) Hack to make type constructors static:
<http://gcc.gnu.org/ml/gcc/2001-04/msg01011.html>. Mark was going to
provide a correct fix for this.
3) NM_FLAG fix:
<http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01058.html>.
4) Full length subspace names:
<http://gcc.gnu.org/ml/gcc/2001-04/msg01067.html>.
5) GNU tools (as, nm, etc.) rather than HP.
I will try to look further into the section name problem tomorrow (I've just
driven 12 hours today). I did notice that HP `nm -p' prints the subspace
names as `t' symbols and they still come out even with "-pg". I will post
full testresults tomorrow.
Dave
--
J. David Anglin dave....@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
2001-01-04 John David Anglin <da...@hiauly1.hia.nrc.ca>
* pa.c (hppa_init_pic_save): Update last_parm_insn after emitting
pic save insn.
--- pa.c.orig Tue Apr 17 14:36:50 2001
+++ pa.c Tue Apr 24 00:03:33 2001
@@ -3359,7 +3359,7 @@
/* Emit the insn at the beginning of the function after the prologue. */
push_topmost_sequence ();
- emit_insn_after (insn, last_parm_insn ? last_parm_insn : get_insns ());
+ last_parm_insn = emit_insn_before (insn, get_first_nonparm_insn ());
pop_topmost_sequence ();
}
Mark Mitchell
2001-04-21 John David Anglin <da...@hiauly1.hia.nrc.ca>
* builtins.c (expand_builtin_setjmp): Mark next_lab as used.
--- builtins.c.orig Wed Feb 7 05:24:22 2001
+++ builtins.c Sat Apr 21 20:18:59 2001
@@ -617,6 +617,7 @@
buf_addr = expand_expr (TREE_VALUE (arglist), NULL_RTX, VOIDmode, 0);
next_lab = gen_label_rtx ();
+ LABEL_PRESERVE_P (next_lab) = 1;
cont_lab = gen_label_rtx ();
expand_builtin_setjmp_setup (buf_addr, next_lab);
Even with this workaround patch I still get a crash using a cross
compiler, so I guess I'll have to wait for Jeff's reworking of Bernd's
patch.
Thanks,
Mark Mitchell
After making Dave work hard sending me lots of information, it turns
out that his original patch is exactly the right thing.
I checked in the attached, on both the mainline and the branch;
hopefully it will remove the duplicate symbols on HPUX.
Tested on i686-pc-linux-gnu, and by looking at the .s output for
Dave's testcase.
Thanks,
--
Mark Mitchell ma...@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
2001-04-25 Mark Mitchell <ma...@codesourcery.com>
* optimize.c (maybe_clone_body): Copy TREE_PUBLIC before emitting
the clone.
Index: optimize.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/optimize.c,v
retrieving revision 1.51.2.13
diff -c -p -r1.51.2.13 optimize.c
*** optimize.c 2001/04/25 00:12:47 1.51.2.13
--- optimize.c 2001/04/26 00:28:07
*************** maybe_clone_body (fn)
*** 1051,1056 ****
--- 1051,1057 ----
DECL_EXTERNAL (clone) = DECL_EXTERNAL (fn);
DECL_INTERFACE_KNOWN (clone) = DECL_INTERFACE_KNOWN (fn);
DECL_NOT_REALLY_EXTERN (clone) = DECL_NOT_REALLY_EXTERN (fn);
+ TREE_PUBLIC (clone) = TREE_PUBLIC (fn);
/* Start processing the function. */
push_to_top_level ();
l...@redhat.com
>
> After making Dave work hard sending me lots of information, it turns
> out that his original patch is exactly the right thing.
>
> I checked in the attached, on both the mainline and the branch;
> hopefully it will remove the duplicate symbols on HPUX.
>
> Tested on i686-pc-linux-gnu, and by looking at the .s output for
> Dave's testcase.
jeff
Mark Mitchell
John> While I am certain that the patch eliminates the duplicate
John> symbols, I am still concerned that assemble_external is
John> being called with TREE_PUBLIC and DECL_EXTERNAL set for the
John> type declarations. This causes .IMPORT statements to be
Yes, that's why I asked about this.
There's a basic problem here; both the C and C++ front-ends call
assemble_external in a way that is inconsistent with the
assemble_external documentation.
In particular, ASM_OUTPUT_EXTERNAL is documented as used when
something is
A C statement (sans semicolon) to output to the stdio stream
STREAM any text necessary for declaring the name of an external
symbol named NAME which is referenced in this compilation but not
defined. The value of DECL is the tree node for the declaration.
You can't know this until the end of the translation unit. But, we
compile a function-at-a-time, so if we see:
extern void f();
void g() { f(); }
void f() {}
we call this macro for `f'.
It's even more extreme in C++ because we don't make up our minds about
the linkages of some functions until very late in the game. (See the
tricks played with DECL_NOT_REALLY_EXTERN.) That's all really pretty
grotesque, but it's not easy to fix, and it's been that way for a long
time, so I'm guessing most systems deal with it OK.
l...@redhat.com
> 2001-01-04 John David Anglin <da...@hiauly1.hia.nrc.ca>
>
> * pa.c (hppa_init_pic_save): Update last_parm_insn after emitting
> pic save insn.
Thanks for tracking this down!
If you want another challenge -- the rethrow1.C test from the g++ testsuite is
getting into an infinite loop. A 2.95.x based compiler does the right thing.
I've started poking at this, but I don't have a real clear understanding of
the C++ language or its EH semantics. About the only tidbit I've got that
might be helpful is that we might be missing a call to cp_pop_exception.
jeff
John David Anglin
> > 2001-01-04 John David Anglin <da...@hiauly1.hia.nrc.ca>
> >
> > * pa.c (hppa_init_pic_save): Update last_parm_insn after emitting
> > pic save insn.
> This is fine for the mainline sources as well as the branch.
>
> Thanks for tracking this down!
Before I installed this, I checked to make sure there were no gcc regressions
in the testsuite with -fPIC. I found that in fact there were some. It looks
like there are problems with the placement of the save instruction when
the first non parameter insn is nil. I think we need to place the save
after the first insn (the one returned by get_insns ()) in this case.
Some of the fails in the testsuite are due to an abort at integrate.c:430
due to first insn not being a note:
;; Function z
(note 2 0 26 NOTE_INSN_DELETED 0)
(insn 26 2 3 (set (reg:SI 98)
(reg:SI 19 %r19)) -1 (nil)
(nil))
(note 3 26 5 NOTE_INSN_FUNCTION_BEG 0)
I am going to go back to the original form and not use
get_first_nonparm_insn (). I think this will fix the problem.
This suggests that there is also a bug in get_eh_context () for
the same reason.
John David Anglin
> getting into an infinite loop. A 2.95.x based compiler does the right thing.
>
> I've started poking at this, but I don't have a real clear understanding of
> the C++ language or its EH semantics. About the only tidbit I've got that
> might be helpful is that we might be missing a call to cp_pop_exception.
I think we need to define builtin_setjmp_receiver to restore r19. The
default exception method I believe is exceptions via longjmp, so we need
this. However, I have no idea whether or not this will fix the problem
with rethrow1.C.
I also noticed a while back that exception_receiver uses a stack offset
of -32 to restore the pic offset table register. This won't work on
the 64-bit target. I think we should restore from the
PIC_OFFSET_TABLE_SAVE_RTX. However, we need to wait for it to be
initialized.
l...@redhat.com
> >>>>> "law" == law <l...@redhat.com> writes:
>
> law> I've started poking at this, but I don't have a real clear
> law> understanding of the C++ language or its EH semantics. About
> law> the only tidbit I've got that might be helpful is that we
> law> might be missing a call to cp_pop_exception.
>
> I'm delighted that we're making progress on HPUX. That's exciting.
>
> Of course, RTH is getting ready to stand EH on its head. So, unless
> this happens on the mainline, it's probaby not worth looking at; the
> whole land of exceptions is going to turn upside down RSN.
I'm really not looking at the mainline at all. I'll put debugging EH stuff
on hold for now and look at other issues.
jeff
Mark Mitchell
law> I've started poking at this, but I don't have a real clear
law> understanding of the C++ language or its EH semantics. About
law> the only tidbit I've got that might be helpful is that we
law> might be missing a call to cp_pop_exception.
I'm delighted that we're making progress on HPUX. That's exciting.
Of course, RTH is getting ready to stand EH on its head. So, unless
this happens on the mainline, it's probaby not worth looking at; the
whole land of exceptions is going to turn upside down RSN.
Thanks,