* Bootstrap failure of gcc-ss-20010409 in ia64 @ 2001-04-11 6:56 Andreas Schwab 2001-04-11 12:47 ` Jim Wilson 0 siblings, 1 reply; 51+ messages in thread From: Andreas Schwab @ 2001-04-11 6:56 UTC (permalink / raw) To: gcc [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 3205 bytes --] gcc-ss-20010409 does not bootstrap on ia64: /bin/sh ../libtool --tag CXX --mode=compile /usr/src/packages/BUILD/gcc-3.0-20010409/obj-ia64-suse-linux/gcc/xgcc -B/usr/src/packages/BUILD/gcc-3.0-20010409/obj-ia64-suse-linux/gcc/ -nostdinc++ -L/usr/src/packages/BUILD/gcc-3.0-20010409/obj-ia64-suse-linux/ia64-suse-linux/libstdc++-v3/src -L/usr/src/packages/BUILD/gcc-3.0-20010409/obj-ia64-suse-linux/ia64-suse-linux/libstdc++-v3/src/.libs -B/usr/ia64-suse-linux/bin/ -B/usr/ia64-suse-linux/lib/ -isystem /usr/ia64-suse-linux/include -nostdinc++ -I../../../../libstdc++-v3/include -I../../../../libstdc++-v3/include/std -I../../../../libstdc++-v3/include/c_std -I../include -I../../../../libstdc++-v3/libsupc++ -I../libio -I../../../../libstdc++-v3/libio -I../../../../libstdc++-v3/libmath -O2 -fvtable-thunks -D_GNU_SOURCE -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -c ../../../../libstdc++-v3/src/string-inst.cc /usr/src/packages/BUILD/gcc-3.0-20010409/obj-ia64-suse-linux/gcc/xgcc -B/usr/src/packages/BUILD/gcc-3.0-20010409/obj-ia64-suse-linux/gcc/ -nostdinc++ -L/usr/src/packages/BUILD/gcc-3.0-20010409/obj-ia64-suse-linux/ia64-suse-linux/libstdc++-v3/src -L/usr/src/packages/BUILD/gcc-3.0-20010409/obj-ia64-suse-linux/ia64-suse-linux/libstdc++-v3/src/.libs -B/usr/ia64-suse-linux/bin/ -B/usr/ia64-suse-linux/lib/ -isystem /usr/ia64-suse-linux/include -nostdinc++ -I../../../../libstdc++-v3/include -I../../../../libstdc++-v3/include/std -I../../../../libstdc++-v3/include/c_std -I../include -I../../../../libstdc++-v3/libsupc++ -I../libio -I../../../../libstdc++-v3/libio -I../../../../libstdc++-v3/libmath -O2 -fvtable-thunks -D_GNU_SOURCE -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -c ../../../../libstdc++-v3/src/string-inst.cc -fPIC -DPIC -o .libs/string-inst.o ../../../../libstdc++-v3/include/bits/basic_string.tcc: In copy constructor `std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]': ../../../../libstdc++-v3/include/bits/basic_string.tcc:187: instantiated from `std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]' ../../../../libstdc++-v3/src/string-inst.cc:48: instantiated from here ../../../../libstdc++-v3/include/bits/basic_string.tcc:187: Internal compiler error in add_abstract_origin_attribute, at dwarf2out.c:9234 Please submit a full bug report, with preprocessed source if appropriate. See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions. Andreas. -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-11 6:56 Bootstrap failure of gcc-ss-20010409 in ia64 Andreas Schwab @ 2001-04-11 12:47 ` Jim Wilson 2001-04-11 17:31 ` Mark Mitchell 2001-04-11 17:43 ` Mark Mitchell 0 siblings, 2 replies; 51+ messages in thread From: Jim Wilson @ 2001-04-11 12:47 UTC (permalink / raw) To: schwab; +Cc: gcc In article < jezodny1za.fsf@hawking.suse.de > you write: >gcc-ss-20010409 does not bootstrap on ia64: This was introduced by a C++ front end change by Mark Mitchell on March 28. See < http://gcc.gnu.org/ml/gcc-bugs/2001-04/msg00081.html >. See also < http://gcc.gnu.org/ml/gcc-bugs/2001-03/msg00879.html > from Alan Modra reporting the same bug for other targets. I believe all DWARF2 targets are broken at the moment. Jim ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-11 12:47 ` Jim Wilson @ 2001-04-11 17:31 ` Mark Mitchell 2001-04-11 17:43 ` Mark Mitchell 1 sibling, 0 replies; 51+ messages in thread From: Mark Mitchell @ 2001-04-11 17:31 UTC (permalink / raw) To: wilson; +Cc: schwab, gcc >>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes: Jim> http://gcc.gnu.org/ml/gcc-bugs/2001-04/msg00081.html I didn't see you're original posting, but I saw this one. I'll look into it. Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-11 12:47 ` Jim Wilson 2001-04-11 17:31 ` Mark Mitchell @ 2001-04-11 17:43 ` Mark Mitchell 2001-04-11 18:28 ` Daniel Berlin ` (2 more replies) 1 sibling, 3 replies; 51+ messages in thread From: Mark Mitchell @ 2001-04-11 17:43 UTC (permalink / raw) To: wilson; +Cc: schwab, gcc >>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes: Jim> This was introduced by a C++ front end change by Mark Jim> Mitchell on March 28. See Jim> < http://gcc.gnu.org/ml/gcc-bugs/2001-04/msg00081.html >. See Jim> also < http://gcc.gnu.org/ml/gcc-bugs/2001-03/msg00879.html > Jim> from Alan Modra reporting the same bug for other targets. I Jim> believe all DWARF2 targets are broken at the moment. Jim -- I tried adding -gdwarf-2 to the command-line on i686-pc-linux-gnu, but I didn't see any problems with the stock 3.0 branch. I will try Alan's .ii file, which is apparently different from the checked-in version. (But, of course, if the problem is related to the difference, then people shouldn't be seeing this elsewhere.) If you send me the usual (target triplet, preprocessed source, cc1plus command-line flags) I will try to figure it out. Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-11 17:43 ` Mark Mitchell @ 2001-04-11 18:28 ` Daniel Berlin 2001-04-11 18:34 ` Mark Mitchell 2001-04-13 19:13 ` Jim Wilson 2001-04-13 19:59 ` Jim Wilson 2 siblings, 1 reply; 51+ messages in thread From: Daniel Berlin @ 2001-04-11 18:28 UTC (permalink / raw) To: Mark Mitchell; +Cc: wilson, schwab, gcc Mark Mitchell <mark@codesourcery.com> writes: > >>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes: > > Jim> This was introduced by a C++ front end change by Mark > Jim> Mitchell on March 28. See > Jim> < http://gcc.gnu.org/ml/gcc-bugs/2001-04/msg00081.html >. See > Jim> also < http://gcc.gnu.org/ml/gcc-bugs/2001-03/msg00879.html > > Jim> from Alan Modra reporting the same bug for other targets. I > Jim> believe all DWARF2 targets are broken at the moment. > > Jim -- > > I tried adding -gdwarf-2 to the command-line on i686-pc-linux-gnu, > but I didn't see any problems with the stock 3.0 branch. I also constantly use dwarf2 with C++, since i'm finishing up moving some stuff from a GDB in C++ rewrite back to GDB, like location expression evaluation at runtime, using the call frame info, redoing some of the symbol structures, etc. I can say for a certainty that all DWARF2 targets are not broken, in the general case. I can also say for a certainty that they are also outputting proper location expressions, even for complex cases. Unless, of course, you have the -feliminate-dwarf2-dups flag somewhere. It's currently outputting broken dwarf2. It does't create references to dies in another CU properly all the time. It ends up getting the offset right, but in the wrong place (IE it's saying it's at an offset in the current compilation unit, when it it's at that offset in *another* compilation unit). forcing it to use absolute die references for everything fixes the problem, so it's certainly just not marking something properly (It attempts to mark all the dies in the current CU to figure out which are referencing things in other CU's) , or something of the sort. > > I will try Alan's .ii file, which is apparently different from the > checked-in version. (But, of course, if the problem is related to the > difference, then people shouldn't be seeing this elsewhere.) > > If you send me the usual (target triplet, preprocessed source, > cc1plus command-line flags) I will try to figure it out. > Ahh, actually, i think i know what's causing this. Reordering the blocks and inlining is causing us to come across a type or declaration, before we normally would (IE where "normal" is the place where we generate the type/decl die.) This happens with templates and inlining, (or at least, it's the only cases i've ever seen it happening), particularly with inlined templated class members. So it goes to add the abstract origin of the die, it tries to lookup the decl/type of the origin, which we don't have. I don't know if this *should* ever happen, but it does. So it aborts. It's likely the cause is that we are deferring outputting whatever the real origin is, but not the actual inlined copy. So when it goes to output the debug info, it hits an inlined copy, with an origin that it hasn't processed yet, and thus, doesn't have the die for in it's tables. A quick fix would be to call gen_decl_die/gen_type_die if the lookups fail, rather than aborting. This is correct if the behavior above is correct. > Thanks, > > -- > Mark Mitchell mark@codesourcery.com > CodeSourcery, LLC http://www.codesourcery.com -- In my house there's this light switch that doesn't do anything. Every so often I would flick it on and off just to check. Yesterday, I got a call from a woman in Germany. She said, "Cut it out." ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-11 18:28 ` Daniel Berlin @ 2001-04-11 18:34 ` Mark Mitchell 2001-04-11 20:24 ` Daniel Berlin 0 siblings, 1 reply; 51+ messages in thread From: Mark Mitchell @ 2001-04-11 18:34 UTC (permalink / raw) To: dan; +Cc: wilson, schwab, gcc Thanks for the analysis. It's certainly the case that we now try to output an inlined instance of a function without having first shown the back end the un-inlined instance. In my opinion, that's a good thing -- there's no need for it to know about anything except what we want it to know about. However, the debug-generation routines need to be able to cope with that. If you can reproduce Jim's problem, maybe you could help him with the solution? I've asked him privately to look into it as quickly as possible -- as a favor to me, the bug-causer -- since it does apparently affect GCC 3.0 bootstraps on some targets. If you were willing to help, that would be great. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-11 18:34 ` Mark Mitchell @ 2001-04-11 20:24 ` Daniel Berlin 2001-04-11 21:19 ` Mark Mitchell 2001-04-13 8:49 ` Andreas Schwab 0 siblings, 2 replies; 51+ messages in thread From: Daniel Berlin @ 2001-04-11 20:24 UTC (permalink / raw) To: Mark Mitchell; +Cc: dan, wilson, schwab, gcc [-- Attachment #1: Type: text/plain, Size: 2217 bytes --] Mark Mitchell <mark@codesourcery.com> writes: > Thanks for the analysis. > > It's certainly the case that we now try to output an inlined instance > of a function without having first shown the back end the un-inlined > instance. In my opinion, that's a good thing -- there's no need for > it to know about anything except what we want it to know about. > > However, the debug-generation routines need to be able to cope with > that. Yes. In fact, the reason i knew about this was because i ran into a similar problem working up a patch to use the correct virtual context for virtual functions (since it's now DECL_VIRTUAL_CONTEXT, not DECL_CONTEXT). We would end up seeing virtual function calls before seeing the type they came from, go to lookup the type die, which wouldn't exist, and segfault. The correct fix, is, of course, to generate the die if it doesn't exist, not segfault. > If you can reproduce Jim's problem, maybe you could help him > with the solution? The attached patch should actually fix it, even though i haven't been able to reproduce it on my platforms. I can't even fathom another explanation for this bug, given it doesn't occur if you turn off inlining, this is the only abort in the area, etc. There are probably a few other places like this case, that need to be fixed in the same way (IE it's likely you may see a similar type of abort or a segfault because of a null value passed somewhere that originated from a lookup of a die or decl) A lot of things don't bother to check if the lookup_{decl,type_die} failed. At least add_abstract_origin was checking the return value and aborting. (add_pure_or_virtual_attribute does the same thing when you give it the correct virtual context sometimes,because without checking, it just passes the result along to anothner function, which promptly crashes trying to deref a null pointer it segfaults in the same type of situation, when you hit a type you haven't hit in the "normal way" first.) > I've asked him privately to look into it as > quickly as possible -- as a favor to me, the bug-causer -- since it > does apparently affect GCC 3.0 bootstraps on some targets. If you > were willing to help, that would be great. > [-- Attachment #2: attrdiff --] [-- Type: text/x-diff, Size: 876 bytes --] Index: dwarf2out.c =================================================================== RCS file: /cvs/gcc/egcs/gcc/dwarf2out.c,v retrieving revision 1.262 diff -c -3 -p -w -B -b -r1.262 dwarf2out.c *** dwarf2out.c 2001/04/05 01:43:17 1.262 --- dwarf2out.c 2001/04/12 03:13:17 *************** add_abstract_origin_attribute (die, orig *** 8537,8545 **** --- 8531,8553 ---- } if (DECL_P (origin)) + { origin_die = lookup_decl_die (origin); + if (origin_die == NULL) + { + gen_decl_die (origin, die->die_parent); + origin_die = lookup_decl_die (origin); + } + } else if (TYPE_P (origin)) + { + origin_die = lookup_type_die (origin); + if (origin_die == NULL) + { + gen_type_die (origin, die->die_parent); origin_die = lookup_type_die (origin); + } + } if (origin_die == NULL) abort (); ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-11 20:24 ` Daniel Berlin @ 2001-04-11 21:19 ` Mark Mitchell 2001-04-11 21:36 ` Daniel Berlin 2001-04-12 13:04 ` Jim Wilson 2001-04-13 8:49 ` Andreas Schwab 1 sibling, 2 replies; 51+ messages in thread From: Mark Mitchell @ 2001-04-11 21:19 UTC (permalink / raw) To: dan; +Cc: wilson, schwab, gcc Daniel - Thanks for the patch. Jim -- Would you mind trying out Daniel's patch? -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-11 21:19 ` Mark Mitchell @ 2001-04-11 21:36 ` Daniel Berlin 2001-04-12 12:27 ` Bill Nottingham 2001-04-12 13:04 ` Jim Wilson 1 sibling, 1 reply; 51+ messages in thread From: Daniel Berlin @ 2001-04-11 21:36 UTC (permalink / raw) To: Mark Mitchell; +Cc: dan, wilson, schwab, gcc Mark Mitchell <mark@codesourcery.com> writes: > Daniel - > > Thanks for the patch. > > Jim -- > > Would you mind trying out Daniel's patch? Please note the patch might not work in all cases, but it should still get you past the point you are at now, and if it does, i'll submit a correct patch. I'm *assuming* the correct place to put the generated decl/type die is the parent of whatever you passed in. Really, we need an extra argument to add_abstract_origin_attribute that is the context to place the decl/type dies we may generate. This is pretty trivial, it just didn't occur to me until I remembered you could have nested inlines, or other cases where you want to place it in some other scope than the parent of the DIE we are generating the abstract attribute for. If the patch works, i'll work up a correct version. > -- > Mark Mitchell mark@codesourcery.com > CodeSourcery, LLC http://www.codesourcery.com -- ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-11 21:36 ` Daniel Berlin @ 2001-04-12 12:27 ` Bill Nottingham 2001-04-12 15:03 ` Daniel Berlin 0 siblings, 1 reply; 51+ messages in thread From: Bill Nottingham @ 2001-04-12 12:27 UTC (permalink / raw) To: dan, Mark Mitchell; +Cc: dan, wilson, schwab, gcc Daniel Berlin <dan@cgsoftware.com> said: >Mark Mitchell <mark@codesourcery.com> writes: >Please note the patch might not work in all cases, but it should still >get you past the point you are at now, and if it does, i'll submit a >correct patch. It doesn't here, in brief testing - it still dies at the same place: /space/ook/gcc-foo/gcc/gcc/xgcc -B/space/ook/gcc-foo/gcc/gcc/ -nostdinc++ -L/space/ook/gcc-foo/gcc/ia64-unknown-linux/libstdc++-v3/src -L/space/ook/gcc-foo/gcc/ia64-unknown-linux/libstdc++-v3/src/.libs -B/usr/local/foo/ia64-unknown-linux/bin/ -B/usr/local/foo/ia64-unknown-linux/lib/ -isystem /usr/local/foo/ia64-unknown-linux/include -nostdinc++ -I../include -I../include/std -I../include/c_std -I../include -I../libsupc++ -I../libio -I../libio -I../libmath -g -O2 -fvtable-thunks -D_GNU_SOURCE -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -c string-inst.cc -fPIC -DPIC -o .libs/string-inst.o ../include/bits/basic_string.tcc: In copy constructor std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]': ../include/bits/basic_string.tcc:187: instantiated from std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]' string-inst.cc:48: instantiated from here ../include/bits/basic_string.tcc:187: Internal compiler error in add_abstract_origin_attribute, at dwarf2out.c:9261 Please submit a full bug report, with preprocessed source if appropriate. See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions. Do you need more info? Bill ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-12 12:27 ` Bill Nottingham @ 2001-04-12 15:03 ` Daniel Berlin 2001-04-12 21:07 ` Bill Nottingham 0 siblings, 1 reply; 51+ messages in thread From: Daniel Berlin @ 2001-04-12 15:03 UTC (permalink / raw) To: Bill Nottingham; +Cc: dan, Mark Mitchell, wilson, schwab, gcc Bill Nottingham <notting@redhat.com> writes: > Daniel Berlin <dan@cgsoftware.com> said: > >Mark Mitchell <mark@codesourcery.com> writes: > >Please note the patch might not work in all cases, but it should still > >get you past the point you are at now, and if it does, i'll submit a > >correct patch. > > It doesn't here, in brief testing - it still dies at the same place: > > Do you need more info? Yes, I need to know what the locals and args look like in gcc when it crashes. Using alan's test file on the same bug report, i am unable to reproduce at all. Umm, actually, are you sure you applied the patch? The abort location should be moved down a few lines, yet it's claiming an ICE at the exact same location it did before (there is no other abort() in that routine). > > Bill -- I installed a skylight in my apartment.... The people who live above me are furious! ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-12 15:03 ` Daniel Berlin @ 2001-04-12 21:07 ` Bill Nottingham 2001-04-12 21:46 ` Daniel Berlin 0 siblings, 1 reply; 51+ messages in thread From: Bill Nottingham @ 2001-04-12 21:07 UTC (permalink / raw) To: dan, Bill Nottingham; +Cc: Mark Mitchell, wilson, schwab, gcc (restating some stuff from private mail) Daniel Berlin <dan@cgsoftware wrote: >Umm, actually, are you sure you applied the patch? > >The abort location should be moved down a few lines, yet it's claiming >an ICE at the exact same location it did before (there is no other >abort() in that routine). Yup, I did apply the patch; I can confirm with this patch in head I can build libstdc++-v3 OK; but it still fails for me on the 3.0 branch in the same place. Bill ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-12 21:07 ` Bill Nottingham @ 2001-04-12 21:46 ` Daniel Berlin 0 siblings, 0 replies; 51+ messages in thread From: Daniel Berlin @ 2001-04-12 21:46 UTC (permalink / raw) To: Bill Nottingham; +Cc: dan, Mark Mitchell, wilson, schwab, gcc Bill Nottingham <notting@redhat.com> writes: > (restating some stuff from private mail) > > Daniel Berlin <dan@cgsoftware wrote: > >Umm, actually, are you sure you applied the patch? > > > >The abort location should be moved down a few lines, yet it's claiming > >an ICE at the exact same location it did before (there is no other > >abort() in that routine). > > Yup, I did apply the patch; I can confirm with this patch in head > I can build libstdc++-v3 OK; but it still fails for me on the > 3.0 branch in the same place. Hmmmm. Odd. Can you capture all the output of a gdb session ("script", for instance, would be fine for this kind of capturing) that just loads cc1, runs it on the preprocessed file till the abort, goes up to the add_abstract_origin frame, runs info locals, and send it to me? I should be able to determine what's up from that. The only thought that comes to me is that either the context is wrong on the generated die (which i know, is the part i need to fix), and for some reason it can find it on the branch, but not the head, or that decl_ultimate_origin is giving us a NULL decl, screwing us since we'll just not generate a die, even if we tell it to. > > Bill -- I can levitate birds. No one cares. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-11 21:19 ` Mark Mitchell 2001-04-11 21:36 ` Daniel Berlin @ 2001-04-12 13:04 ` Jim Wilson 2001-04-12 15:06 ` Daniel Berlin 1 sibling, 1 reply; 51+ messages in thread From: Jim Wilson @ 2001-04-12 13:04 UTC (permalink / raw) To: Mark Mitchell; +Cc: dan, schwab, gcc I applied the patch by hand to the gcc trunk. It didn't apply automatically, I don't know why. I did a make all, and libstdc++ built without error. Not too surprising, because the patch is creating the missing dies at the point where we notice that they are missing. It isn't obvious that this is the right fix, but Dan's explanation is pretty convincing, so it sounds like this is the right approach. Jim ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-12 13:04 ` Jim Wilson @ 2001-04-12 15:06 ` Daniel Berlin 0 siblings, 0 replies; 51+ messages in thread From: Daniel Berlin @ 2001-04-12 15:06 UTC (permalink / raw) To: Jim Wilson; +Cc: Mark Mitchell, dan, schwab, gcc Jim Wilson <wilson@cygnus.com> writes: > I applied the patch by hand to the gcc trunk. It didn't apply automatically, > I don't know why. Probably my fault, I had to hand edit out an irrelevant change or two, related to trying to get dwarf2 elimination working again. I must have accidently removed one line too many. I checked out a new copy to do the work to make the patch work all the time, so it shouldn't happen again. > I did a make all, and libstdc++ built without error. > Not too surprising, because the patch is creating the missing dies at the > point where we notice that they are missing. It isn't obvious that this is > the right fix, but Dan's explanation is pretty convincing, so it sounds like > this is the right approach. Well, Mark says this *can* happen, in normal cases, so IMHO, it's the right thing to do. There's certainly no other way around it than to create the DIE's, they must exist to be able to set the attribute :). I'll make the patch put the decl's and type's in the right place all the time, and submit it. > > Jim -- The other day, I was walking my dog around my building... on the ledge. Some people are afraid of heights. Not me, I'm afraid of widths. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-11 20:24 ` Daniel Berlin 2001-04-11 21:19 ` Mark Mitchell @ 2001-04-13 8:49 ` Andreas Schwab 2001-04-13 10:04 ` Daniel Berlin 1 sibling, 1 reply; 51+ messages in thread From: Andreas Schwab @ 2001-04-13 8:49 UTC (permalink / raw) To: Daniel Berlin; +Cc: Mark Mitchell, wilson, gcc [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 564 bytes --] Daniel Berlin <dan@cgsoftware.com> writes: |> The attached patch should actually fix it, even though i haven't been able to |> reproduce it on my platforms. It does not change anything. lookup_decl_die still returns NULL after gen_decl_die has been called. Andreas. -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-13 8:49 ` Andreas Schwab @ 2001-04-13 10:04 ` Daniel Berlin 2001-04-13 10:23 ` Andreas Schwab 0 siblings, 1 reply; 51+ messages in thread From: Daniel Berlin @ 2001-04-13 10:04 UTC (permalink / raw) To: Andreas Schwab; +Cc: Daniel Berlin, Mark Mitchell, wilson, gcc [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1764 bytes --] Andreas Schwab <schwab@suse.de> writes: > Daniel Berlin <dan@cgsoftware.com> writes: > > |> The attached patch should actually fix it, even though i haven't been able to > |> reproduce it on my platforms. > > It does not change anything. lookup_decl_die still returns NULL after > gen_decl_die has been called. It does work on the HEAD, probably due to another bugfix somewhere else. The likely cause for not working on the branch is that gen_decl_die isn't doing anything. This happens if the DECL is marked to be ignored, or it's an ERROR_MARK, or it's a CONST_DECL (an enum), etc. In fact, diffing the HEAD dwarf2out against the branch shows me there are only two changes in the way we generate dies, neither of which would have any affect whatsoever on this bug. Looking at the changelogs between the head and the branch, and based on timing, A random guess as to what made this start working on the head, is a 2001-03-21 change by Jason (look at the head cp/ChangeLog) that involved changing a few things about templates. I can guarantee you the real bug isn't in dwarf2out (once you have the patch installed), because if we aren't generating the decl die, something is set wrong, somewhere. Can you see why gen_decl_die isn't generating the die? (IE what case it's breaking/returning on) This should give you a large clue as to what is wrong. --Dan > > Andreas. > > -- > Andreas Schwab "And now for something > SuSE Labs completely different." > Andreas.Schwab@suse.de > SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg > Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 -- Factorials were someone's attempt to make math *look* exciting. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-13 10:04 ` Daniel Berlin @ 2001-04-13 10:23 ` Andreas Schwab 2001-04-13 12:20 ` Daniel Berlin 0 siblings, 1 reply; 51+ messages in thread From: Andreas Schwab @ 2001-04-13 10:23 UTC (permalink / raw) To: Daniel Berlin; +Cc: Mark Mitchell, wilson, gcc [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1735 bytes --] Daniel Berlin <dan@cgsoftware.com> writes: |> Can you see why gen_decl_die isn't generating the die? (IE what case |> it's breaking/returning on) This should give you a large clue as to |> what is wrong. The condition `(class_scope_p (context_die) || DECL_ABSTRACT (decl))' in gen_variable_die is false (context_die.die_tag == DW_TAG_subprogram). This is the value of decl: <var_decl 0x2000000000b07d80 __exception_info type <pointer_type 0x2000000000529740 type <record_type 0x2000000000529680 cp_eh_info asm_written type_5 BLK size <integer_cst 0x20000000004d6a00 constant 512> unit size <integer_cst 0x2000000000456ac0 constant 64> user align 64 symtab 2411472 alias set -1 fields <field_decl 0x2000000000529800 eh_info> n_parents 0 use_template=0 interface-unknown pointer_to_this <pointer_type 0x2000000000529740> chain <type_decl 0x2000000000529e00 cp_eh_info>> unsigned asm_written DI size <integer_cst 0x2000000000305a40 constant 64> unit size <integer_cst 0x2000000000305a70 constant 8> align 64 symtab 2416272 alias set -1> unsigned used DI file /cvs/snapshot/gcc/libstdc++-v3/include/bits/basic_string.h line 189 size <integer_cst 0x2000000000305a40 64> unit size <integer_cst 0x2000000000305a70 8> align 64 context <function_decl 0x2000000000c22f40 _M_refcopy> initial <call_expr 0x2000000000b01500>> Andreas. -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-13 10:23 ` Andreas Schwab @ 2001-04-13 12:20 ` Daniel Berlin 2001-04-13 12:39 ` Andreas Schwab 0 siblings, 1 reply; 51+ messages in thread From: Daniel Berlin @ 2001-04-13 12:20 UTC (permalink / raw) To: Andreas Schwab; +Cc: Daniel Berlin, Mark Mitchell, wilson, gcc [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1172 bytes --] Andreas Schwab <schwab@suse.de> writes: > Daniel Berlin <dan@cgsoftware.com> writes: > > |> Can you see why gen_decl_die isn't generating the die? (IE what case > |> it's breaking/returning on) This should give you a large clue as to > |> what is wrong. > > The condition `(class_scope_p (context_die) || DECL_ABSTRACT (decl))' in > gen_variable_die is false (context_die.die_tag == DW_TAG_subprogram). > This is the value of decl: Oh, then this is because it's putting the die in the wrong context, which is the thing i said was wrong with the patch. Doh. Change the gen_decl_die (origin, die->die_parent) to dwarf2out_decl (origin), and see if it goes away. > > Andreas. > > -- > Andreas Schwab "And now for something > SuSE Labs completely different." > Andreas.Schwab@suse.de > SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg > Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 -- I went to the hardware store and bought some used paint. It was in the shape of a house. I also bought some batteries, but they weren't included. So I had to buy them again. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-13 12:20 ` Daniel Berlin @ 2001-04-13 12:39 ` Andreas Schwab 2001-04-13 12:56 ` Daniel Berlin 0 siblings, 1 reply; 51+ messages in thread From: Andreas Schwab @ 2001-04-13 12:39 UTC (permalink / raw) To: Daniel Berlin; +Cc: Mark Mitchell, wilson, gcc [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 561 bytes --] Daniel Berlin <dan@cgsoftware.com> writes: |> Change the gen_decl_die (origin, die->die_parent) to dwarf2out_decl |> (origin), and see if it goes away. That didn't help either. context_die.die_tag is now DW_TAG_compile_unit, but no difference otherwise. Andreas. -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-13 12:39 ` Andreas Schwab @ 2001-04-13 12:56 ` Daniel Berlin 2001-04-13 13:06 ` Andreas Schwab 0 siblings, 1 reply; 51+ messages in thread From: Daniel Berlin @ 2001-04-13 12:56 UTC (permalink / raw) To: Andreas Schwab; +Cc: Daniel Berlin, Mark Mitchell, wilson, gcc [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1268 bytes --] Andreas Schwab <schwab@suse.de> writes: > Daniel Berlin <dan@cgsoftware.com> writes: > > |> Change the gen_decl_die (origin, die->die_parent) to dwarf2out_decl > |> (origin), and see if it goes away. > > That didn't help either. context_die.die_tag is now DW_TAG_compile_unit, > but no difference otherwise. Darn it, this sucks. It thinks it's not a declaration, so it never equates the number. I'm curious, in gen_variable_die, is the local "declaration" getting set to 1? If so, modify the class_scope_p test that before equate_decl_number_with_die to if (declaration || DECL_ABSTRACT (decl)) equate_decl_number_to_die (decl, var_die); At least we know why it doesn't happen in the head, however. It's because the exception handling stuff changed, so we don't hit this particular type anymore. > > Andreas. > > -- > Andreas Schwab "And now for something > SuSE Labs completely different." > Andreas.Schwab@suse.de > SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg > Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 -- I went to the cinema, and the prices were: Adults $5.00, children $2.50. So I said, "Give me two boys and a girl." ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-13 12:56 ` Daniel Berlin @ 2001-04-13 13:06 ` Andreas Schwab 0 siblings, 0 replies; 51+ messages in thread From: Andreas Schwab @ 2001-04-13 13:06 UTC (permalink / raw) To: Daniel Berlin; +Cc: Mark Mitchell, wilson, gcc [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 438 bytes --] Daniel Berlin <dan@cgsoftware.com> writes: |> I'm curious, in gen_variable_die, is the local "declaration" getting |> set to 1? No. Andreas. -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-11 17:43 ` Mark Mitchell 2001-04-11 18:28 ` Daniel Berlin @ 2001-04-13 19:13 ` Jim Wilson 2001-04-13 19:59 ` Jim Wilson 2 siblings, 0 replies; 51+ messages in thread From: Jim Wilson @ 2001-04-13 19:13 UTC (permalink / raw) To: Mark Mitchell; +Cc: schwab, gcc, wilson My work on the IA-64 port has been hampered lately because I've been running into too many different regressions all at the same time. I found four serious regressions all at about the same time. Disentagling all of the problems has been hard. 1) The trunk was broken by Richard's large C++ EH/Unwind API patch which went in without any IA-64 support. This caused builds to break early, during the stage1 gcc build. This patch did not go on the branch. This was fixed by hacking the trunk to use setjmp/longjmp EH for IA-64, which is something that still needs to be fixed. Hopefully the same breakage won't go on the branch when this patch gets moved to the branch. If so, that will make use of the gcc3 branch undesirable for IA-64 C++ code. 2) The branch was broken by your patch to throttle C++ inlining. This patch went on both the trunk and the branch. This caused builds to fail late, during the target libstdc++ build. At the time, I assumed both the branch and trunk were broken because of this patch, but that I couldn't see the problem on the trunk because of the large C++ EH patch. That seems to be mistaken as I haven't been able to reproduce the problem on the trunk. 3) I discovered that debugging binaries built by gcc no longer worked right. If I use the assembler that comes with my OS release, gdb reports the right line number but the wrong filename when debugging a stage2 cc1plus on the trunk. This makes debugging difficult, but still possible. If I try the binutils 2.11 assembler, I get gdb segfaults debugging a stage2 cc1plus on the trunk. This make debugging impossible. This has forced me to build stage1 cc1plus binaries to be able to debug C++ testcases. I suspect this is related to the dwarf2out.c file table changes in gcc and binutils by Richard et al. I also see similar problems on the gcc3 branch. 4) An IA-64 backend patch I wrote to fix a linux kernel miscompilation problem triggered a latent assembler problem. This was discovered after binutils 2.11. has been released. This forces me to use an up-to-date assembler for gcc builds now. Unfortunately, using an up-to-date assembler exacerbates the above problem #3. It will take some time for me to get all of these problems resolved. For the moment, just concentrating on the one problem that you are asking about, problem #2... The problem is easy to reproduce on the branch. We get the dwarf2out.c abort when compiling libstdc++. I can reproduce this with a native ia64-linux compiler, and with a cross from x86-linux to ia64-linux. I haven't been able to reproduce the problem on the trunk. I checked out a copy of the trunk using -D"March 27, 2001", which includes your C++ throttling patch, but none of Richard's C++ EH/Unwind API patch. The problem does not show up there. So my earlier comment about Dan's patch working on the trunk should be disregarded. Curiously, the testcase does not fail with a native x86-linux compiler. That may be because of the IA-64 built-in function used by the testcase, or it may be because an optimization pass (like reorder-blocks) is changing the decls in a machine dependent way that only causes the problem to show up for some targets. The testcase fails on the branch because of the __exception_info symbol. This disappears with Richard's patch, thus there is a chance that the problem will go away when Richard's patch goes on the branch. Interestingly, this symbol is still present on the trunk in the March 27 tree I checked out, but the problem does not show up there. Hence I suspect that it is just an accident that the problem is showing up with this symbol on the branch, and that Richard's patch won't actually make the problem go away, but rather will just make it a latent problem. The real problem is probably elsewhere, though it could be in any of the C++ front end, the dwarf2out.c file, the IA-64 back-end, or in the optimizer. At the moment, I haven't spent any significant time debugging dwarf2out to see if I can identify the problem. I'm very close to finishing problem #4, the linux kernel miscompilation and latent assembler bug. After I resolve these problems, I will spend some more time looking into the dwarf2out.c abort. I will also have to look at the dwarf2 file table problem sometime soon. Not being able to debug stage2/stage3 gcc binaries makes it hard to work on build failures, so this is also a serious problem even though it doesn't cause an obvious build failure. I did spend some time creating a smaller testcase to make the problem easier to debug. The following testcase is 86 lines, and aborts in dwarf2out.c for an ia64-linux target when compiled with -O2 -S -g. This testcase can probably be reduced even further, but I was at the point of diminishing returns, plus I have limited C++ knowledge and wasn't sure how to simplify some parts of the testcase. template<class _CharT> struct char_traits; template<typename _Alloc> class allocator; template<typename _CharT, typename _Traits = char_traits<_CharT>, typename _Alloc = allocator<_CharT> > class basic_string; template <class _Tp> class allocator { public: ~allocator() throw() {} }; static inline void __attribute__ ((__unused__)) __atomic_add (int* __mem, int __val) { __sync_fetch_and_add_si (__mem, __val); } template<typename _CharT, typename _Traits, typename _Alloc> class basic_string { public: typedef _Alloc allocator_type; private: struct _Rep { int _M_references; bool _M_is_leaked() const { return _M_references < 0; } _CharT* _M_refdata() throw() { return reinterpret_cast<_CharT*> (this + 1); } _CharT* _M_grab(const _Alloc& __alloc1, const _Alloc& __alloc2) { return (!_M_is_leaked()) ? _M_refcopy() : _M_clone(__alloc1); } _CharT* _M_refcopy() throw() { __atomic_add(&_M_references, 1); return _M_refdata(); } _CharT* _M_clone(const _Alloc&); }; struct _Alloc_hider : _Alloc { _Alloc_hider(_CharT* __dat, const _Alloc& __a) : _Alloc(__a), _M_p(__dat) { } _CharT* _M_p; }; mutable _Alloc_hider _M_dataplus; _CharT* _M_data() const { return _M_dataplus._M_p; } _Rep* _M_rep() const { return &((reinterpret_cast<_Rep*> (_M_data()))[-1]); } public: basic_string(const basic_string& __str); }; template<typename _CharT, typename _Traits, typename _Alloc> basic_string<_CharT, _Traits, _Alloc>:: basic_string(const basic_string& __str) : _M_dataplus(__str._M_rep()->_M_grab(_Alloc(), _Alloc ()), _Alloc ()) { } template class basic_string<char>; ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-11 17:43 ` Mark Mitchell 2001-04-11 18:28 ` Daniel Berlin 2001-04-13 19:13 ` Jim Wilson @ 2001-04-13 19:59 ` Jim Wilson 2001-04-14 2:01 ` Jim Wilson 2 siblings, 1 reply; 51+ messages in thread From: Jim Wilson @ 2001-04-13 19:59 UTC (permalink / raw) To: Mark Mitchell; +Cc: wilson, schwab, gcc It appears that entropy still has the upper hand. I have to add another item to the list 5) libffi fails to build. It seems that this has been broken for a while, but did not show up because libffi wasn't getting configured. Now that it gets configured, it causes obvious build failures. However, it isn't obvious why it is getting configured now when it didn't use to be. Jim ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-13 19:59 ` Jim Wilson @ 2001-04-14 2:01 ` Jim Wilson 2001-04-14 4:08 ` Sam TH 2001-04-16 15:39 ` Bootstrap failure of gcc-ss-20010409 in ia64 Jim Wilson 0 siblings, 2 replies; 51+ messages in thread From: Jim Wilson @ 2001-04-14 2:01 UTC (permalink / raw) To: Mark Mitchell; +Cc: wilson, schwab, gcc My libffi problems are because it has been too long since I last did a cvs co on my main gcc tree. I normally just do a cvs update, but that doesn't give you new directories. After doing a cvs co to get new directories, libffi now configures and builds as it should. There are two libffi build problems, but both are trivial to fix. I have patches for both, but have not tested them yet. Meanwhile, I've spent about 4 hours looking at the dwarf2out.c abort. Mostly all I accomplished was to remember how it works, but I did learn a few things. The problem is with <var_decl 0x401f4ea0 __exception_info> which is nested inside a base_ctor function. This var_decl has an abstract origin of <var_decl 0x401d5f08 __exception_info> which has a context of <function_decl 0x401b8ea0 _M_refcopy>. When we try to add an abtract_origin attribute pointing at the 0x401d5f08 decl, we first call dwarf2out_abstract_ function on _M_refcopy. Unfortunately, there is no __execption_info var_decl inside the _M_refcopy block tree, and thus we still have no origin_die, and we hit the abort. This is definitely fishy. We have a decl that claims to be inside a function, but the function claims to not know anything about the decl. I will have to investigate this further. I can throw out a few wild guesses though, based on the fact that the problem goes away when -freorder-blocks is turned off. a) We generate a M_refcopy function that contains a __exception_info variable. We inline this into another function, generating an exception_info var with an abstract origin pointing back to us. We then optimize and emit M_refcopy, and in the process of doing so, the block tree is modified such that the exception_info variable no longer exists. We then later try to emit debug info for the inlinee, and we find a decl whose abstract origin no longer exists. This problem does not exist with the RTL inliner, because we make a copy of the inline function before optimizing and emitting it, and hence all abstract origin pointers back to us remain valid. b) We generate a M_refcopy function that does not contain a __exception_info variable. We inline this into another function that does contain an _exception_info variable in other blocks. We then optimize and emit the inlinee, and in the process of doing so we modify the block tree in such a way that we now have an exception_info variable inside the inlined M_refcopy function. We we try to look for it inside the M_refcopy function we can't find it, and we end up aborting. 'b' seems pretty unlikely, as that would require that a DECL_CONTEXT field get clobbered, and I don't think that -freorder-blocks can do that. 'a' seems plausible though. By the way, -freorder-blocks is known to have at least one other seriously bad interaction with dwarf2out.c. See http://gcc.gnu.org/ml/gcc-bugs/2001-03/msg00434.html This problem causes ia64-linux glibc build failures unless either -g or -freorder-blocks is turned off. This same problem has also been reported for other linux systems, see the links at the bottom of the above message. If the current problem is also a -freorder-blocks/dwarf2 interaction problem, then perhaps -freorder-blocks shouldn't be on by default. Jim ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-14 2:01 ` Jim Wilson @ 2001-04-14 4:08 ` Sam TH 2001-04-14 8:27 ` cvs (was: Bootstrap failure of gcc-ss-20010409 in ia64) Fergus Henderson 2001-04-16 15:39 ` Bootstrap failure of gcc-ss-20010409 in ia64 Jim Wilson 1 sibling, 1 reply; 51+ messages in thread From: Sam TH @ 2001-04-14 4:08 UTC (permalink / raw) To: Jim Wilson; +Cc: Mark Mitchell, wilson, schwab, gcc On Sat, Apr 14, 2001 at 02:01:13AM -0700, Jim Wilson wrote: > My libffi problems are because it has been too long since I last did a cvs co > on my main gcc tree. I normally just do a cvs update, but that doesn't give > you new directories. After doing a cvs co to get new directories, libffi now You do know about cvs update -P, right? That gives you new directories too. sam th --- sam@uchicago.edu --- http://www.abisource.com/~sam/ OpenPGP Key: CABD33FC --- http://samth.dyndns.org/key DeCSS: http://samth.dyndns.org/decss -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE62DI8t+kM0Mq9M/wRAgAxAKCySRe9WopP1hrPNAN9Thh6JHiwLwCgpXGb M3Z+pHM91WnwlyJRRmm0T2o= =lBk7 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 51+ messages in thread
* cvs (was: Bootstrap failure of gcc-ss-20010409 in ia64) 2001-04-14 4:08 ` Sam TH @ 2001-04-14 8:27 ` Fergus Henderson 2001-04-14 11:28 ` Sam TH 2001-04-14 22:20 ` Jim Wilson 0 siblings, 2 replies; 51+ messages in thread From: Fergus Henderson @ 2001-04-14 8:27 UTC (permalink / raw) To: Sam TH, Jim Wilson, gcc On 14-Apr-2001, Sam TH <sam@uchicago.edu> wrote: > On Sat, Apr 14, 2001 at 02:01:13AM -0700, Jim Wilson wrote: > > My libffi problems are because it has been too long since I last did a cvs co > > on my main gcc tree. I normally just do a cvs update, but that doesn't give > > you new directories. After doing a cvs co to get new directories, libffi now > > You do know about cvs update -P, right? That gives you new > directories too. I think you mean `-d'. `-P' is for pruning empty directories. But yes, generally it's a very good idea to put update -d -P in your ~/.cvsrc, so that you use `-d' and `-P' by default. The defaults that cvs uses for many commands are not ideal, and in my experience it's usually best to use a .cvsrc such as the one attached to override them. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit | of excellence is a lethal habit" WWW: < http://www.cs.mu.oz.au/~fjh > | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cvs (was: Bootstrap failure of gcc-ss-20010409 in ia64) 2001-04-14 8:27 ` cvs (was: Bootstrap failure of gcc-ss-20010409 in ia64) Fergus Henderson @ 2001-04-14 11:28 ` Sam TH 2001-04-14 22:20 ` Jim Wilson 1 sibling, 0 replies; 51+ messages in thread From: Sam TH @ 2001-04-14 11:28 UTC (permalink / raw) To: Fergus Henderson; +Cc: Jim Wilson, gcc On Sun, Apr 15, 2001 at 01:27:49AM +1000, Fergus Henderson wrote: > On 14-Apr-2001, Sam TH <sam@uchicago.edu> wrote: > > On Sat, Apr 14, 2001 at 02:01:13AM -0700, Jim Wilson wrote: > > > My libffi problems are because it has been too long since I last did a cvs co > > > on my main gcc tree. I normally just do a cvs update, but that doesn't give > > > you new directories. After doing a cvs co to get new directories, libffi now > > > > You do know about cvs update -P, right? That gives you new > > directories too. > > I think you mean `-d'. `-P' is for pruning empty directories. Doh. But yeah, put both in your .cvsrc, and forget about it. sam th --- sam@uchicago.edu --- http://www.abisource.com/~sam/ OpenPGP Key: CABD33FC --- http://samth.dyndns.org/key DeCSS: http://samth.dyndns.org/decss -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE62Jl2t+kM0Mq9M/wRAhWKAJ9/w7VozGoOk2lDgaHT/NP6VPnbJQCfWETR DxvOpLH1AjFnX1ocfOVAZUU= =7H2t -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cvs (was: Bootstrap failure of gcc-ss-20010409 in ia64) 2001-04-14 8:27 ` cvs (was: Bootstrap failure of gcc-ss-20010409 in ia64) Fergus Henderson 2001-04-14 11:28 ` Sam TH @ 2001-04-14 22:20 ` Jim Wilson 2001-04-14 23:48 ` Russ Allbery 1 sibling, 1 reply; 51+ messages in thread From: Jim Wilson @ 2001-04-14 22:20 UTC (permalink / raw) To: Fergus Henderson, Sam TH; +Cc: gcc > update -d -P I'm aware of -d, but it isn't appropriate for all cases. If you used a module to check out a subset of a repository, then using update -d will give you files that were not part of the module that you checked out. This isn't really a problem with the FSF gcc repository, since the gcc module is the entire repository. It is a problem for other repositories that I use, for instance the combined gdb/binutils repository on sources.redhat.com. If I check out the binutils module, and then update it, I don't want update to check out gdb files. Thus I can't use -d. Also, -d gives you new directories, but it doesn't give you new files. This matters if you checked out a module that includes specific filenames in addition to directory names. If someone later modifies the module to include additional filenames, then update -d will not give you those additional filenames. This isn't a problem for the FSF gcc repository, since we aren't using modules that way, but it is a problem for other repositories that I use. Neither problem exists if you use co instead of update. Thus it is always better to use co instead of update -d. However, this does require you to remember to do a co occasionally. For people that don't use as many CVS features I do, which is probably most people, update -d will work fine. Jim ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cvs (was: Bootstrap failure of gcc-ss-20010409 in ia64) 2001-04-14 22:20 ` Jim Wilson @ 2001-04-14 23:48 ` Russ Allbery 0 siblings, 0 replies; 51+ messages in thread From: Russ Allbery @ 2001-04-14 23:48 UTC (permalink / raw) To: gcc Jim Wilson <wilson@cygnus.com> writes: > Neither problem exists if you use co instead of update. Thus it is > always better to use co instead of update -d. Last time I tried this, cvs co always sent the entire file across the connection, while cvs update knew how to generate a patch and send that instead if the changes were small or the file large. Thus there was an advantage to using update instead of co if update wouldn't cause problems. I don't know if this is still the case, though. I'd need to experiment further. -- Russ Allbery (rra@stanford.edu) < http://www.eyrie.org/~eagle/ > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-14 2:01 ` Jim Wilson 2001-04-14 4:08 ` Sam TH @ 2001-04-16 15:39 ` Jim Wilson 2001-04-16 17:22 ` Mark Mitchell 1 sibling, 1 reply; 51+ messages in thread From: Jim Wilson @ 2001-04-16 15:39 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc >a) We generate a M_refcopy function that contains a __exception_info variable. > We inline this into another function, generating an exception_info var > with an abstract origin pointing back to us. We then optimize and emit > M_refcopy, and in the process of doing so, the block tree is modified such > that the exception_info variable no longer exists. We then later try to > emit debug info for the inlinee, and we find a decl whose abstract origin > no longer exists. This problem does not exist with the RTL inliner, because > we make a copy of the inline function before optimizing and emitting it, > and hence all abstract origin pointers back to us remain valid. I have now verified that this is true. When we get to M_refcopy, the C++ front end generates an AST which is saved in DECL_SAVED_TREE. This contains an __exception_info variable. We then generate BLOCK trees and RTL from the AST, putting the block trees in DECL_INITIAL. At this point, the block trees contain an __exception_info variable. We then optimize and emit the M_refcopy function. The optimizer function reorder_basic_blocks massages the RTL and block tree. At this point, there is no longer any __exception_info variable. We then emit assembly language and debug info for M_refcopy. Later, we inline the M_refcopy function into the M_grab function. The tree inliner in the C++ front end uses the DECL_SAVED_TREE for this. The DECL_SAVED_TREE still contains references to an __exception_info variable, so we end up with one inlined into M_grab, whose abstract origin points back to M_refcopy. When we later emit debug info for M_grab (actually in my case, another function that M_grab was inlined into), we follow the abstract origin pointer back to M_refcopy, but there is no __exception_info variable in M_refcopy, and we abort. So the problem here is that a function only has one block tree, but we really need two, one for the abstract instance, and one for the concrete out-of-line instance (to use dwarf2 terminology). This wasn't a problem with the older RTL inliner for a couple of reasons that I can see. Firstly, we only had one representation for a function, the block trees and the RTL. If we optimized a function, and then later used the optimized block tree/RTL for inlining, then everything remains consistent. Now however we have two representations for a function, the AST in DECL_SAVED_TREE, and the block tree/RTL. After optimization, these are no longer consistent with each other. Secondly, the RTL inliner would make copies of the block tree before optimizing a function in some instance, and this ensured that the original abstract instance block trees survived for use by the debug output routines. I see of couple of different ways to fix this. We could try to make the dwarf2out.c file use the DECL_SAVED_TREE instead of the block tree when emitting debug info for an abstract instance. This info is not in the form that we want it, and hence this will require writing a bit of code. Another possible solution is to modify the FUNCTION_DECL tree to have two block trees, the original one created by the front ends, and an optimized one. When emitting debug info for an abstract instance, we use the original block tree. When emitting debug info for a concrete out-of-line instance, we use the optimized block tree. Both of these solutions will require writing some non-trivial code and then debugging and testing it. Possible simpler solutions, which may not be desirable, are turning the RTL inliner back on, and disabling optimization passes that can delete blocks from the block tree (e.g. -freorder-blocks). Jim ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-16 15:39 ` Bootstrap failure of gcc-ss-20010409 in ia64 Jim Wilson @ 2001-04-16 17:22 ` Mark Mitchell 2001-04-16 17:45 ` Jim Wilson 0 siblings, 1 reply; 51+ messages in thread From: Mark Mitchell @ 2001-04-16 17:22 UTC (permalink / raw) To: wilson; +Cc: gcc >>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes: Jim> Possible simpler solutions, which may not be desirable, are Jim> turning the RTL inliner back on, and disabling optimization Jim> passes that can delete blocks from the block tree Jim> (e.g. -freorder-blocks). Would omitting debugging information for these variables be another short-term solution? -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-16 17:22 ` Mark Mitchell @ 2001-04-16 17:45 ` Jim Wilson 2001-04-17 8:22 ` Mark Mitchell 0 siblings, 1 reply; 51+ messages in thread From: Jim Wilson @ 2001-04-16 17:45 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc >Would omitting debugging information for these variables be another >short-term solution? Not emitting the abstract origin attribute would be easy. This will give a die with no type or size info, which is pretty useless. I suspect gdb will give a reasonable error message instead of failing, but haven't tried it yet. For a slightly more complicated change, we could check to see if the abstract origin attribute was emitted, and if not, then treat it like a non-inlined local variable. This would allow the user to still be able to look at the variable, but the output would be a little confusing since the debugger would claim that we have a variable that doesn't exist in the source code. My IA-64 machine is tied up with patch testing at the moment, so I can't do much more with this until tomorrow. Jim ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-16 17:45 ` Jim Wilson @ 2001-04-17 8:22 ` Mark Mitchell 2001-04-17 8:57 ` Daniel Berlin 2001-04-17 11:01 ` Jim Wilson 0 siblings, 2 replies; 51+ messages in thread From: Mark Mitchell @ 2001-04-17 8:22 UTC (permalink / raw) To: wilson; +Cc: gcc >>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes: Jim> Not emitting the abstract origin attribute would be easy. Jim> This will give a die with no type or size info, which is Jim> pretty useless. I suspect gdb will give a reasonable error Jim> message instead of failing, but haven't tried it yet. Jim> For a slightly more complicated change, we could check to see Jim> if the abstract origin attribute was emitted, and if not, Jim> then treat it like a non-inlined local variable. This would Jim> allow the user to still be able to look at the variable, but Jim> the output would be a little confusing since the debugger Jim> would claim that we have a variable that doesn't exist in the Jim> source code. I think either of these two alternatives would be fine. In my experience, using GDB to debug optimized, heavily inlined code really has never worked. You tend not to be able to see variables, you tend to find that step/next work oddly, and often you end up jumping entirely out of the function spontaneously. So, I guess I don't think this will be a major inconvenience to anyone, relative to the current state. In the long run, we should do better, but it sounds like these changes would do the trick for GCC 3.0. At this point, we have to be looking for minimalist solutions. Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-17 8:22 ` Mark Mitchell @ 2001-04-17 8:57 ` Daniel Berlin 2001-04-17 11:01 ` Jim Wilson 1 sibling, 0 replies; 51+ messages in thread From: Daniel Berlin @ 2001-04-17 8:57 UTC (permalink / raw) To: Mark Mitchell; +Cc: wilson, gcc On Tue, 17 Apr 2001, Mark Mitchell wrote: > >>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes: > > Jim> Not emitting the abstract origin attribute would be easy. > Jim> This will give a die with no type or size info, which is > Jim> pretty useless. I suspect gdb will give a reasonable error > Jim> message instead of failing, but haven't tried it yet. > > Jim> For a slightly more complicated change, we could check to see > Jim> if the abstract origin attribute was emitted, and if not, > Jim> then treat it like a non-inlined local variable. This would > Jim> allow the user to still be able to look at the variable, but > Jim> the output would be a little confusing since the debugger > Jim> would claim that we have a variable that doesn't exist in the > Jim> source code. > > I think either of these two alternatives would be fine. > > In my experience, using GDB to debug optimized, heavily inlined code > really has never worked. You tend not to be able to see variables, > you tend to find that step/next work oddly, and often you end up > jumping entirely out of the function spontaneously. Just a note, for the "long run". This is something i'm seriously working on currently. It's why I sent patches to support location lists for dwarf2 (well, one of the reasons, anyway). I already have modified loop unrolling to keep track of the approriate things so that when combined with a patch to start using location lists for my modified range rtlin dwarf2out.c (I removed some useless things from the range info, since we no longer need to be tracking state for the register allocator, just knowing enough to produce the debug info), and can successfully handle location lists, and evaluation of them at runtiome, in gdb. So when the IV gets split into 4, we still can print the right value at the right place, although step and next are still a little confusing. I'm working on that too, but it's a little trickier of a change (I can already read and do some stuff with the call frame info, which is basically necessary to be able to treat inline functions as if they had their own frame), so it's taking time. Obviously, i'm not shooting for the 3.0 timeframe, i just wanted to make sure nobody thought the "long run" was 5 years from now, when it's probably 7 or 8 months. > > So, I guess I don't think this will be a major inconvenience to > anyone, relative to the current state. > > In the long run, we should do better, but it sounds like these changes > would do the trick for GCC 3.0. At this point, we have to be looking > for minimalist solutions. > > Thanks, > > -- > Mark Mitchell mark@codesourcery.com > CodeSourcery, LLC http://www.codesourcery.com > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-17 8:22 ` Mark Mitchell 2001-04-17 8:57 ` Daniel Berlin @ 2001-04-17 11:01 ` Jim Wilson 2001-04-17 15:38 ` Mark Mitchell 1 sibling, 1 reply; 51+ messages in thread From: Jim Wilson @ 2001-04-17 11:01 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc How about hacking the gcc3 branch and leaving the trunk broken? That way we have a chance of getting the trunk fixed correctly in the long term. It would be a shame to deliberately modify the trunk to emit incorrect debug info. Jim ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-17 11:01 ` Jim Wilson @ 2001-04-17 15:38 ` Mark Mitchell 2001-04-17 16:16 ` Daniel Berlin 2001-04-18 12:41 ` Bootstrap failure of gcc-ss-20010409 in ia64 Jim Wilson 0 siblings, 2 replies; 51+ messages in thread From: Mark Mitchell @ 2001-04-17 15:38 UTC (permalink / raw) To: wilson; +Cc: gcc >>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes: Jim> How about hacking the gcc3 branch and leaving the trunk Jim> broken? That way we have a chance of getting the trunk fixed If you like; that's OK with me. Jim> correctly in the long term. It would be a shame to Jim> deliberately modify the trunk to emit incorrect debug info. Well, sort-of. We're talking about a case where optimization is involved, and as laudable a goal as making debugging work well with optimizatio is, it's unattainable, in general. The debugger can't really be expected to print out information about the values of variables that were optimized away, for example. The solution you proposed (replicating the BLOCK tree) might be expensive, and I'm not convinced that's worth the trouble. It would be better if the optimizers did not mess up the tree structure; they are supposed to be working on RTL, not trees. Perhaps the RTL could contain the declarations explicitly (via a NOTE_DECL_START_SCOPE NOTE_DECL_END_SCOPE or some such); that would make it easier to keep things in a consistent state. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-17 15:38 ` Mark Mitchell @ 2001-04-17 16:16 ` Daniel Berlin 2001-04-17 16:36 ` Mark Mitchell 2001-04-18 14:35 ` debugging optimized programs (Was: Re: Bootstrap failure of gcc-ss-20010409 in ia64) Joern Rennecke 2001-04-18 12:41 ` Bootstrap failure of gcc-ss-20010409 in ia64 Jim Wilson 1 sibling, 2 replies; 51+ messages in thread From: Daniel Berlin @ 2001-04-17 16:16 UTC (permalink / raw) To: Mark Mitchell; +Cc: wilson, gcc Mark Mitchell <mark@codesourcery.com> writes: > >>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes: > > Jim> How about hacking the gcc3 branch and leaving the trunk > Jim> broken? That way we have a chance of getting the trunk fixed > > If you like; that's OK with me. > > Jim> correctly in the long term. It would be a shame to > Jim> deliberately modify the trunk to emit incorrect debug info. > > Well, sort-of. > > We're talking about a case where optimization is involved, and as > laudable a goal as making debugging work well with optimizatio is, > it's unattainable, in general. The debugger can't really be expected > to print out information about the values of variables that were > optimized away, for example. This is the only case that is "unattainable". You can track values over their lifetime, even if they are split into several pieces, first 2bytes in a register, next two in memory, etc, over a specific range. We can make it so inlined functions look just like the normal function call to users in the debugger. We can deal with the absence of frames, with multiple prologues and epilogues, with scheduled prologues and epilogues, you name it. In fact, the only optimization we actually can't handle yet (DWARF 2.1 introduces support for it), is interprocedural optimizations that cause parts of a variable or function to be in different text sections at once. Past that, it's certainly attainable. And i'm working on it quite hard. In fact, the reason discontiguous scope support and whatnot is going into DWARF2 2.1 is because their are compilers and debuggers that can do everything else, and this is one of the last things they need to be able to support. To quote a proposal from the dwarf2 committe " In general, you can provide a highly useful level of debugging optimized programs with the following: Representing split lifetimes for variables Representing subprogram inlining Representing discontiguous scopes Representing semantic breakpoint locations. DWARF2 supports the first two, this proposal handles the third. The fourth will be the subject of an upcoming proposal" Please, don't claim something is unattainable when i've *seen* it done with my own eyes. I've used debuggers and compilers that support optimized debugging, using dwarf2, to a point that except for variables that were optimized out, i couldn't tell the difference between the optimized version, and the non-optimized one, for debugging. I'd like GDB and GCC to be able to do this too. > > The solution you proposed (replicating the BLOCK tree) might be > expensive, and I'm not convinced that's worth the trouble. It would > be better if the optimizers did not mess up the tree structure; they > are supposed to be working on RTL, not trees. Perhaps the RTL could > contain the declarations explicitly (via a NOTE_DECL_START_SCOPE > NOTE_DECL_END_SCOPE or some such); that would make it easier to keep > things in a consistent state. > > -- > Mark Mitchell mark@codesourcery.com > CodeSourcery, LLC http://www.codesourcery.com -- I saw a subliminal advertising executive, but only for a second. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-17 16:16 ` Daniel Berlin @ 2001-04-17 16:36 ` Mark Mitchell 2001-04-18 14:35 ` debugging optimized programs (Was: Re: Bootstrap failure of gcc-ss-20010409 in ia64) Joern Rennecke 1 sibling, 0 replies; 51+ messages in thread From: Mark Mitchell @ 2001-04-17 16:36 UTC (permalink / raw) To: dan; +Cc: wilson, gcc >>>>> "Daniel" == Daniel Berlin <dan@cgsoftware.com> writes: Daniel> This is the only case that is "unattainable". You can I'm all for all the fancy DWARF2 stuff; I'd love to have it, and I'm glad you're working on it. (I was actually an advocate of getting rid of stabs, in favor of DWARF, a couple of years ago on these lists). But, there are other things that are very hard to do, often because something is just not there in the compiler output. Like instantiate a class that the compiler didn't see a use of, and therefore didn't emit debugging information for. Or set a breakpoint at a line that has been optimized away. Or call an inlined function from the debugger if no out-of-line instance was emitted by the compiler. Or making it easy for a programmer to follow the control flow with `step' in the debugger when the compiler has reordered the code. Some of these things might be important; some might not. Some, you could simulate. But, there are problems that are hard. Bottom line: a statement like this Please, don't claim something is unattainable when i've *seen* it done with my own eyes. is more inflammatory than it needs to be, and suggests that I don't know about these things. The point is that debugging optimized code will always be harder thatn debugging unoptimized code. It would be good if are debug information was perfect for optimized code. But, it's more important that it be perfect for unoptimized code (and I bet it's not!), and it's even more important that we generate correct code (which I know we don't always). Not to mention improving GDB to have a better user interface, better stability, etc. (Thanks to you for working on this!) It's a question of priorities, cost-benefit analysis, etc. Is it worth the effort (both programmer-time and compiler-time) to do what Jim suggested, or is better just to punt? I think we all agree punting is OK for the 3.0 branch. The question is whether to punt on the 3.1 mainline, or not. If we do, then some people argue that we are less likely to fix the bug. On the other hand, if we do not punt, then if we don't fix the bug, we must remember to insall the punt again on the 3.1 release branch, when we get there. And meanwhile some programs will crash on the mainline. Personally, I would prefer that we file a bug in GNATS (debugging info wrong; here's a test-case) and install the punt on both the mainline and the branch. That adheres to the principle of trying to keep things working as much as possible so that a) it's easier to do releases, and b) it's easier for everyone to test the compiler and work to improve it. A broken compiler may serve as a good reminder, but it also makes life difficult for people working on unrelated tasks. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 51+ messages in thread
* debugging optimized programs (Was: Re: Bootstrap failure of gcc-ss-20010409 in ia64) 2001-04-17 16:16 ` Daniel Berlin 2001-04-17 16:36 ` Mark Mitchell @ 2001-04-18 14:35 ` Joern Rennecke 2001-04-18 15:12 ` Daniel Berlin 1 sibling, 1 reply; 51+ messages in thread From: Joern Rennecke @ 2001-04-18 14:35 UTC (permalink / raw) To: Daniel Berlin; +Cc: Mark Mitchell, wilson, gcc > I've used debuggers and compilers that support optimized debugging, > using dwarf2, to a point that except for variables that were optimized > out, i couldn't tell the difference between the optimized version, and > the non-optimized one, for debugging. So what does the debugger do when you ask it to step one source level line forward (gdb 'n' command) when code from different lines is heavily intermingled by scheduling? ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: debugging optimized programs (Was: Re: Bootstrap failure of gcc-ss-20010409 in ia64) 2001-04-18 14:35 ` debugging optimized programs (Was: Re: Bootstrap failure of gcc-ss-20010409 in ia64) Joern Rennecke @ 2001-04-18 15:12 ` Daniel Berlin 2001-04-18 15:49 ` Joern Rennecke 0 siblings, 1 reply; 51+ messages in thread From: Daniel Berlin @ 2001-04-18 15:12 UTC (permalink / raw) To: Joern Rennecke; +Cc: Daniel Berlin, Mark Mitchell, wilson, gcc Joern Rennecke <amylaar@cambridge.redhat.com> writes: > > I've used debuggers and compilers that support optimized debugging, > > using dwarf2, to a point that except for variables that were optimized > > out, i couldn't tell the difference between the optimized version, and > > the non-optimized one, for debugging. > > So what does the debugger do when you ask it to step one source level line > forward (gdb 'n' command) when code from different lines is heavily > intermingled by scheduling? The line number information will tell it when it's actually advanced one source line. is_stmt will tell you when you hit the first thing that actually belongs to that particularl line. In the case of heavily intermingled code, the line number info may look like (i've omitted is_stmt, basic_block, and other registers, for simplicity): Line advance Address advance 0 1 -1 1 2 1 -1 1 etc -- "I'm writing a book. I've got the page numbers done, so now I just have to fill in the rest. "-Steven Wright ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: debugging optimized programs (Was: Re: Bootstrap failure of gcc-ss-20010409 in ia64) 2001-04-18 15:12 ` Daniel Berlin @ 2001-04-18 15:49 ` Joern Rennecke 2001-04-18 17:06 ` Daniel Berlin 0 siblings, 1 reply; 51+ messages in thread From: Joern Rennecke @ 2001-04-18 15:49 UTC (permalink / raw) To: Daniel Berlin; +Cc: Joern Rennecke, Daniel Berlin, Mark Mitchell, wilson, gcc > In the case of heavily intermingled code, the line number info may > look like (i've omitted is_stmt, basic_block, and other registers, for > simplicity): > > Line advance Address advance > 0 1 > -1 1 > 2 1 > -1 1 > etc So that's the way gdb handles it right now. Which can mean that optimized code is so tedious to debug for some applications and targets that you try to avoid it at all costs. Not what I'd call 'not being able to tell the difference'. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: debugging optimized programs (Was: Re: Bootstrap failure of gcc-ss-20010409 in ia64) 2001-04-18 15:49 ` Joern Rennecke @ 2001-04-18 17:06 ` Daniel Berlin 2001-04-18 17:18 ` Daniel Berlin 0 siblings, 1 reply; 51+ messages in thread From: Daniel Berlin @ 2001-04-18 17:06 UTC (permalink / raw) To: Joern Rennecke; +Cc: Daniel Berlin, Mark Mitchell, wilson, gcc Joern Rennecke <amylaar@cambridge.redhat.com> writes: > > In the case of heavily intermingled code, the line number info may > > look like (i've omitted is_stmt, basic_block, and other registers, for > > simplicity): > > > > Line advance Address advance > > 0 1 > > -1 1 > > 2 1 > > -1 1 > > etc > > So that's the way gdb handles it right now. Which can mean that > optimized code is so tedious to debug for some applications and targets > that you try to avoid it at all costs. Not what I'd call 'not being able > to tell the difference'. Err, what are you talking about? I mean this is what the debug info says, not what gdb *does* (or will do). -- "I put a new engine in my car, but forgot to take the old one out. Now my car goes 500 miles per hour. The harmonica sounds *amazing*. "-Steven Wright ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: debugging optimized programs (Was: Re: Bootstrap failure of gcc-ss-20010409 in ia64) 2001-04-18 17:06 ` Daniel Berlin @ 2001-04-18 17:18 ` Daniel Berlin 0 siblings, 0 replies; 51+ messages in thread From: Daniel Berlin @ 2001-04-18 17:18 UTC (permalink / raw) To: Daniel Berlin; +Cc: Joern Rennecke, Mark Mitchell, wilson, gcc Daniel Berlin <dan@cgsoftware.com> writes: > Joern Rennecke <amylaar@cambridge.redhat.com> writes: > > > > In the case of heavily intermingled code, the line number info may > > > look like (i've omitted is_stmt, basic_block, and other registers, for > > > simplicity): > > > > > > Line advance Address advance > > > 0 1 > > > -1 1 > > > 2 1 > > > -1 1 > > > etc > > > > So that's the way gdb handles it right now. Which can mean that > > optimized code is so tedious to debug for some applications and targets > > that you try to avoid it at all costs. Not what I'd call 'not being able > > to tell the difference'. > > Err, what are you talking about? > I mean this is what the debug info says, not what gdb *does* (or will > do). Let me expand. What GDB does is take this, and throw it all away. It says a line can have a pc range, but it can't be discontiguous. So we can't actually follow what really happens, we just go to the source line past the end of the range for that line, etc. If we did something like the above, we'd at least always be on the right line when you type step or next (step would skip around as the line we are on decrements or advances, but it'd be correct. next would do what it says, and go to the next source line. In other words, next just wouldn't follow negative line advances). --Dan -- "I saw a bank that said "24 Hour Banking", but I don't have that much time. "-Steven Wright ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-17 15:38 ` Mark Mitchell 2001-04-17 16:16 ` Daniel Berlin @ 2001-04-18 12:41 ` Jim Wilson 2001-04-18 13:49 ` Mark Mitchell 1 sibling, 1 reply; 51+ messages in thread From: Jim Wilson @ 2001-04-18 12:41 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc Just a few more comments on what you and other people have said... This particular problem with the debug info did not exist until you checked in a patch that turned off the RTL inliner. As such, it represents a regression, and regressions should be fixed. I see this as another part of the tree inliner that isn't finished yet. The RTL inliner handled this correctly. It is easy for the tree inliner to handle this correctly too, we just haven't written the code for it yet. This should be done before the tree inliner permanently replaces the RTL inliner. It is easy to disregard debug info related problems because they don't interfere with bootstraps. However, debug info support is important for maintaining gcc and other programs, and a lot of people have put a lot of hard work into making the debug info useful. We should not lightly abandon that effort. The breakage here is not as serious as it might seem. Remember, the trunk is not broken because of this bug, only the branch. This is because the bug goes away with Richard's large C++ EH/Unwind API patch. The only testcase we have for this problem fails because of fake variables inserted by the C++ front end for EH purposes. It is unclear if this bug will be triggered by any other testcases. Richard will be checking his patch onto the branch before long, so the problem will go away even if we don't do anything to dwarf2out.c. I'm still working on java related build failures on the trunk that appeared recently. I expect that I will get to this problem today. I will check in a patch to punt on the branch, and then document the correct fix in dwarf2out.c on the trunk, or if it isn't too hard, I may just write the damn code myself. Jim ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-18 12:41 ` Bootstrap failure of gcc-ss-20010409 in ia64 Jim Wilson @ 2001-04-18 13:49 ` Mark Mitchell 2001-04-18 14:34 ` Jim Wilson 0 siblings, 1 reply; 51+ messages in thread From: Mark Mitchell @ 2001-04-18 13:49 UTC (permalink / raw) To: wilson; +Cc: gcc >>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes: Jim> This particular problem with the debug info did not exist Jim> until you checked in a patch that turned off the RTL inliner. Jim> As such, it represents a regression, and regressions should Jim> be fixed. That's fair. Jim> I see this as another part of the tree inliner that isn't Jim> finished yet. The RTL inliner handled this correctly. It is Jim> easy for the tree inliner to handle this correctly too, we Jim> just haven't written the code for it yet. This should be Jim> done before the tree inliner permanently replaces the RTL Jim> inliner. I guess I'm still not sure exactly what needs to be done. Is all that needs to be done: If the function for which we are about to generate code is inline, then: - Copy the BLOCK tree. - Generate code. - Restore the original BLOCK tree, throwing away the copy. ? If so, you're correct that that isn't a particularly difficult task. I can certainly code that up, given a test-case, and such. I don't know if it's really that simple, or not. Jim> they don't interfere with bootstraps. However, debug info Jim> support is important for maintaining gcc and other programs, Jim> and a lot of people have put a lot of hard work into making Jim> the debug info useful. We should not lightly abandon that Jim> effort. I agree completely. Jim> large C++ EH/Unwind API patch. The only testcase we have for Jim> this problem fails because of fake variables inserted by the Jim> C++ front end for EH purposes. It is unclear if this bug Jim> will be triggered by any other testcases. Interesting point. It is likely that it could be -- the front-end doesn't really do anything special with those variables -- but your point that we don't know how often the bug will come up is interesting. Jim> problem today. I will check in a patch to punt on the Jim> branch, and then document the correct fix in dwarf2out.c on Jim> the trunk, or if it isn't too hard, I may just write the damn Jim> code myself. Thank you, for the analysis, the commentary, and the fix. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-18 13:49 ` Mark Mitchell @ 2001-04-18 14:34 ` Jim Wilson 2001-04-18 15:31 ` Mark Mitchell 0 siblings, 1 reply; 51+ messages in thread From: Jim Wilson @ 2001-04-18 14:34 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc > - Copy the BLOCK tree. > - Generate code. > - Restore the original BLOCK tree, throwing away the copy. That is one solution. Another solution is to modify dwarf2out.c to use the DECL_SAVED_TREE instead of the BLOCK tree for abstract instances. Neither one should be particularly hard. Jim ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-18 14:34 ` Jim Wilson @ 2001-04-18 15:31 ` Mark Mitchell 0 siblings, 0 replies; 51+ messages in thread From: Mark Mitchell @ 2001-04-18 15:31 UTC (permalink / raw) To: wilson; +Cc: gcc >>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes: >> - Copy the BLOCK tree. - Generate code. - Restore the >> original BLOCK tree, throwing away the copy. Jim> That is one solution. Another solution is to modify Jim> dwarf2out.c to use the DECL_SAVED_TREE instead of the BLOCK Jim> tree for abstract instances. Neither one should be Jim> particularly hard. The DECL_SAVED_TREE approach is probably harder because the block tree is not so clearly encoded there. Is note_outlining_of_inline_function being called? It looks like: void note_outlining_of_inline_function (fndecl) tree fndecl; { #ifdef DWARF2_DEBUGGING_INFO /* The DWARF 2 backend tries to reduce debugging bloat by not emitting the abstract description of inline functions until something tries to reference them. Force it out now, before optimizations mangle the block tree. */ if (write_symbols == DWARF2_DEBUG) dwarf2out_abstract_function (fndecl); #endif } From the comment, it sounds like this code should be dealing with this problem. If this function isn't being called, then that's a front-end bug -- but probably one that can be easily fixed. Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 @ 2001-04-17 18:12 Mike Stump 2001-04-17 19:01 ` Joe Buck 0 siblings, 1 reply; 51+ messages in thread From: Mike Stump @ 2001-04-17 18:12 UTC (permalink / raw) To: dan, mark; +Cc: gcc, wilson > To: Mark Mitchell <mark@codesourcery.com> > Cc: wilson@cygnus.com, gcc@gcc.gnu.org > From: Daniel Berlin <dan@cgsoftware.com> > Date: 17 Apr 2001 19:16:23 -0400 > > The debugger can't really be expected to print out information > > about the values of variables that were optimized away, for > > example. > This is the only case that is "unattainable". Actually, if you can make it spit out 5, when a user says p i, when the software has a { const int i = 5; } then I don't see why you can't mostly solve the last as well. In fact, I thought dwarf 2 had enough guts to do this. If not that, maybe p i with { enum { i = 5 }; }? ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-17 18:12 Mike Stump @ 2001-04-17 19:01 ` Joe Buck 2001-04-17 20:38 ` Daniel Berlin 0 siblings, 1 reply; 51+ messages in thread From: Joe Buck @ 2001-04-17 19:01 UTC (permalink / raw) To: Mike Stump; +Cc: dan, mark, gcc, wilson > > > The debugger can't really be expected to print out information > > > about the values of variables that were optimized away, for > > > example. > > This is the only case that is "unattainable". Mike Stump writes: > Actually, if you can make it spit out 5, when a user says p i, when > the software has a { const int i = 5; } then I don't see why you can't > mostly solve the last as well. In fact, I thought dwarf 2 had enough > guts to do this. I suppose we could give the debugger a formula for re-generating things like loop induction variables that get optimized away. Kind of like a spreadsheet, defining no longer existing variables in terms of existing objects, perhaps different for each location. But there also can be variables that are neither used nor set, so their value is indeterminate. Or because a variable is not used, the compiler throws away a lot of code that computes it, and it might be tricky to include all needed formulas to compute it. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Bootstrap failure of gcc-ss-20010409 in ia64 2001-04-17 19:01 ` Joe Buck @ 2001-04-17 20:38 ` Daniel Berlin 0 siblings, 0 replies; 51+ messages in thread From: Daniel Berlin @ 2001-04-17 20:38 UTC (permalink / raw) To: Joe Buck; +Cc: Mike Stump, dan, mark, gcc, wilson Joe Buck <jbuck@racerx.synopsys.com> writes: > > > > The debugger can't really be expected to print out information > > > > about the values of variables that were optimized away, for > > > > example. > > > This is the only case that is "unattainable". > > Mike Stump writes: > > Actually, if you can make it spit out 5, when a user says p i, when > > the software has a { const int i = 5; } then I don't see why you can't > > mostly solve the last as well. In fact, I thought dwarf 2 had enough > > guts to do this. > > I suppose we could give the debugger a formula for re-generating things > like loop induction variables that get optimized away. Or, it can say "variable doesn't exist during this range". DWARF2 lets you do either. > Kind of like a > spreadsheet, defining no longer existing variables in terms of existing > objects, perhaps different for each location. This is actually pretty easy to do, given the opcodes available in dwarf2 locexpr's. > > But there also can be variables that are neither used nor set, so their > value is indeterminate. Or because a variable is not used, the compiler > throws away a lot of code that computes it, and it might be tricky to > include all needed formulas to compute it. If it's been optimized away for a givne range, we can express this to the debugger, with location lists. Any range of pc's for which you have no location means the variable doesn't exist during that range. Any range of pc's that overlap means you have a variable that exists in two places simultaneously. > > -- Last night, I walked up to this beautiful woman in a bar and asked her, "Do you live around here often?" She said, "You're wearing two different colored socks." I said, "Yes, but to me they're the same because I go by thickness." Then she asked, "How do you feel?" and I said, "Well, you know when you're sitting on a chair and you lean back so you're just on two legs then you lean too far and you almost fall over but at the last second you catch yourself? I feel like that all the time." ^ permalink raw reply [flat|nested] 51+ messages in thread
end of thread, other threads:[~2001-04-18 17:18 UTC | newest] Thread overview: 51+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-04-11 6:56 Bootstrap failure of gcc-ss-20010409 in ia64 Andreas Schwab 2001-04-11 12:47 ` Jim Wilson 2001-04-11 17:31 ` Mark Mitchell 2001-04-11 17:43 ` Mark Mitchell 2001-04-11 18:28 ` Daniel Berlin 2001-04-11 18:34 ` Mark Mitchell 2001-04-11 20:24 ` Daniel Berlin 2001-04-11 21:19 ` Mark Mitchell 2001-04-11 21:36 ` Daniel Berlin 2001-04-12 12:27 ` Bill Nottingham 2001-04-12 15:03 ` Daniel Berlin 2001-04-12 21:07 ` Bill Nottingham 2001-04-12 21:46 ` Daniel Berlin 2001-04-12 13:04 ` Jim Wilson 2001-04-12 15:06 ` Daniel Berlin 2001-04-13 8:49 ` Andreas Schwab 2001-04-13 10:04 ` Daniel Berlin 2001-04-13 10:23 ` Andreas Schwab 2001-04-13 12:20 ` Daniel Berlin 2001-04-13 12:39 ` Andreas Schwab 2001-04-13 12:56 ` Daniel Berlin 2001-04-13 13:06 ` Andreas Schwab 2001-04-13 19:13 ` Jim Wilson 2001-04-13 19:59 ` Jim Wilson 2001-04-14 2:01 ` Jim Wilson 2001-04-14 4:08 ` Sam TH 2001-04-14 8:27 ` cvs (was: Bootstrap failure of gcc-ss-20010409 in ia64) Fergus Henderson 2001-04-14 11:28 ` Sam TH 2001-04-14 22:20 ` Jim Wilson 2001-04-14 23:48 ` Russ Allbery 2001-04-16 15:39 ` Bootstrap failure of gcc-ss-20010409 in ia64 Jim Wilson 2001-04-16 17:22 ` Mark Mitchell 2001-04-16 17:45 ` Jim Wilson 2001-04-17 8:22 ` Mark Mitchell 2001-04-17 8:57 ` Daniel Berlin 2001-04-17 11:01 ` Jim Wilson 2001-04-17 15:38 ` Mark Mitchell 2001-04-17 16:16 ` Daniel Berlin 2001-04-17 16:36 ` Mark Mitchell 2001-04-18 14:35 ` debugging optimized programs (Was: Re: Bootstrap failure of gcc-ss-20010409 in ia64) Joern Rennecke 2001-04-18 15:12 ` Daniel Berlin 2001-04-18 15:49 ` Joern Rennecke 2001-04-18 17:06 ` Daniel Berlin 2001-04-18 17:18 ` Daniel Berlin 2001-04-18 12:41 ` Bootstrap failure of gcc-ss-20010409 in ia64 Jim Wilson 2001-04-18 13:49 ` Mark Mitchell 2001-04-18 14:34 ` Jim Wilson 2001-04-18 15:31 ` Mark Mitchell 2001-04-17 18:12 Mike Stump 2001-04-17 19:01 ` Joe Buck 2001-04-17 20:38 ` Daniel Berlin
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).