From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: muller@cerbere.u-strasbg.fr Cc: gdb@sourceware.cygnus.com Subject: Re: Pascal language support patch preparation Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003021508.e22F8og07862@delius.kettenis.local> References: <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003021452.PAA02334@cerbere.u-strasbg.fr> X-SW-Source: 2000-q1/msg00508.html Date: Thu, 02 Mar 2000 15:36:54 +0100 From: Pierre Muller The logs are also useless as most only are weekly imports from the workers CVS before the CVS was made public! Looks like we need to teach you the concept of ChangeLogs :-). Take a look at the files named ChangeLog* in the GDB source directory of your checked out sources. They list all the changes made to the sources over the years. Preferably you would include ChangeLog entries with you patches too. Mark >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: hollerer@gmx.net Cc: gdb@sourceware.cygnus.com Subject: Re: remote debugging via rs332c - output lost Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38951B76.E2AC3DCE@cygnus.com> References: X-SW-Source: 2000-q1/msg00075.html Content-length: 690 Quality Quorum wrote: > > On Wed, 12 Jan 2000 hollerer@gmx.net wrote: > > > hi, > > > > i am remote debugging programs which makes output > > like > > printf("xxx called\r\n"); > > > > it outputs the string on it's serial interface. > > the same interface as used for gdb. > > debugging generally works. but the host gdb does not > > show the sent string. > > what must i do that the host gdb shows output of the > > remote program? > > wrap it into 'O' message. To expand a little on this. You will need to encode the output string using the ``O'' packet . See "Communication protocol" http://sourceware.cygnus.com/gdb/onlinedocs/gdb_14.html#SEC115 (the URL may be wrong). Andrew >From eliz@gnu.org Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: Jim Kingdon Cc: Andrew Cagney , gdb@sourceware.cygnus.com Subject: Re: New file gdb/CONTRIBUTE guidelins for the contributor Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002111929.OAA13997@mescaline.gnu.org> References: <38A3B39A.D3C7650C@cygnus.com> <38A3780F.2FE7A510@cygnus.com> X-SW-Source: 2000-q1/msg00225.html Content-length: 492 Andrew Cagney writes: > > So having said all that, do you still want submit.html or equivalent > > in the distribution? Having it both places seems like kind of a > > maintenance pain and seems to me that having the distribution point > > to the web site probably works. > > Yes, I think the GDB distribution should contain the document. Perhaps it is better to make this document part of the GDB manual. Then we could be sure it won't be forgotten due to changing fortunes of time... >From mark@codesourcery.com Sat Apr 01 00:00:00 2000 From: Mark Mitchell To: Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE Cc: kingdon@redhat.com, donnte@microsoft.com, gdb@sourceware.cygnus.com Subject: Re: Regressions problem (200 failures) Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000302023420H.mitchell@codesourcery.com> References: <200003021010.LAA13693@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-q1/msg00493.html Content-length: 762 >>>>> "Peter" == Peter Schauer writes: Peter> For practical debugging purposes (especially C++), the line Peter> number information (and thus the breakpoint) has to be put Peter> before the initialization code for local variables, so that Peter> we can debug object initialization. But the line number itself doesn't have to indicate the `{'; it could indicate the next line, if that's what GDB wants. This is more possible than it used to be since the C++ front-end now puts out whole functions at once, rather than processing a statement at a time. Still, it's non-trivial. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com >From guo@cup.hp.com Sat Apr 01 00:00:00 2000 From: Jimmy Guo To: "Daniel Berlin+mail.gdb" Cc: gdb@sourceware.cygnus.com Subject: Re: RTTI working for G++ Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: X-SW-Source: 2000-q1/msg00726.html Content-length: 10093 >> ... However, one of the fixes was that when print >> object is on, and one wants to print member / methods of the derived >> type, you can now do so. > >See, i didn't consider that a bug, i considered it a lacking >feature. It just wasn't doing the lookup it would need to do, and i've >been too busy to fix it. If 'print foo' says it's a pointer to something, and 'print foo->a' says 'There is no member or method named a.', it's very confusing to the user. When print object is on, this could happen. I'd be more willing to say it's a bug, since the error message contradicts with what print says and just misleads user ('which one should I believe from this debugger?'). The fix is in eval.c (evaluate_subexp_standard): it needs to know if objectprint is set, and if so, return the pointer to the rtti type when dealing with STUCTOP_PTR (if target type code is TYPE_CODE_CLASS). >> Besides, there're some fixes to handle pointer >> to a derived type and explicit casting of a pointer to a base to a >> derived type. > >This i ran up against. I also handled reference types (By pretending >they were pointers). Actually the example you gave at the end of this email looks like something I fixed, in the casting code. I'm not familiar with value_rtti_type and don't quite understand what you were dealing with -- full, etc. are all reset to initial values upon entry into value_rtti_type (). >Did you notice that it's not really fun to use value_nid (damn >flyspell keeps "correcting" the IND to nid, as if "nid" was really a word >either.) in value_rtti_type? value_nid will call the RTTI routine >during it's lazy evaluation, which gets you into a recursive nightmare >if you aren't careful. I wasn't adventuring into that area since I'm looking at the higher layer of the proper handling of casting, printing, and expression evaluation. >I'd be glad to incorporate your fixes into my patch, and i'd >appreciate it if you'd look at mine. >I'll post it to gdb-patches in a few days. Mine is enclosed in this email. >I'm a little confused about the semantics of using_enc/full/top in value_rtti_type. > >It seems if i set full to 0, on multiple inheritance, it gets the name >right, but the offset wrong, so you have the right name, and the wrong >values. >If i set full to 1, it gets the name wrong ("suspicious *", which >means it couldn't look it up right), but the values right. See if my changes to c-valprint.c and valops.c solved your problem. I think at least part of the problem is that the pointer value was _not_ adjusted when you change the type of the thing to a rtti type, which is fixed in these two files. c-valprint.c deals with printing the pointer value itself; valops.c deals with printing a member of the pointer value. Patch follows (the change to typeprint.c probably conflicts with your version, and I like the output you provided). - Jimmy Guo, guo@cup.hp.com Thu Mar 16 15:49:56 2000 Jimmy guo * c-valprint.c (c_value_print): adjust pointer value when objectprint is set and pointer type is changed to point to the rtti type. * eval.c (evaluate_subexp_standard): for OP_VAR_VALUE, always return full value object; for STRUCTOP_PTR, use pointer to rtti type to get member / method if objectprint is set and target type of pointer is class. * typeprint.c (whatis_exp): if objectprint is set and exp is of pointer / reference type to a class object, look up and print the pointer / reference to rtti type. * valops.c (value_cast): when casting a pointer / reference type of a class object to pointer / refer to its rtti type, adjust the new pointer value accordingly. Index: c-valprint.c /usr/local/bin/diff -c -w -L c-valprint.c c-valprint.c@@/main/cygnus/7 c-valprint.c *** c-valprint.c --- c-valprint.c Thu Mar 16 10:21:16 2000 *************** *** 497,502 **** --- 497,505 ---- /* create a reference type referencing the real type */ type = lookup_reference_type (real_type); } + /* JYG: Need to adjust pointer value. */ + val->aligner.contents[0] -= top; + /* Note: When we look up RTTI entries, we don't get any information on const or volatile attributes */ } Index: eval.c /usr/local/bin/diff -c -w -L eval.c eval.c@@/main/cygnus/9 eval.c *** eval.c --- eval.c Thu Mar 16 15:41:34 2000 *************** *** 37,42 **** --- 37,45 ---- /* This is defined in valops.c */ extern int overload_resolution; + /* JYG: lookup rtti type of STRUCTOP_PTR when this is set to continue + on with successful lookup for member/method of the rtti type. */ + extern int objectprint; /* Prototypes for local functions. */ *************** *** 428,459 **** (*pos) += 3; if (noside == EVAL_SKIP) goto nosideret; - if (noside == EVAL_AVOID_SIDE_EFFECTS) - { - struct symbol *sym = exp->elts[pc + 2].symbol; - enum lval_type lv; - - switch (SYMBOL_CLASS (sym)) - { - case LOC_CONST: - case LOC_LABEL: - case LOC_CONST_BYTES: - lv = not_lval; - break; ! case LOC_REGISTER: ! case LOC_REGPARM: ! lv = lval_register; ! break; - default: - lv = lval_memory; - break; - } - - return value_zero (SYMBOL_TYPE (sym), lv); - } - else return value_of_variable (exp->elts[pc + 2].symbol, exp->elts[pc + 1].block); --- 431,446 ---- (*pos) += 3; if (noside == EVAL_SKIP) goto nosideret; ! /* JYG: We used to just return value_zero of the symbol type ! if we're asked to avoid side effects. Otherwise we return ! value_of_variable (...). However I'm not sure if ! value_of_variable () has any side effect. ! We need a full value object returned here for whatis_exp () ! to call evaluate_type () and then pass the full value to ! value_rtti_target_type () if we are dealing with a pointer ! or reference to a base class and print object is on. */ return value_of_variable (exp->elts[pc + 2].symbol, exp->elts[pc + 1].block); *************** *** 1051,1056 **** --- 1038,1068 ---- arg1 = evaluate_subexp (NULL_TYPE, exp, pos, noside); if (noside == EVAL_SKIP) goto nosideret; + + /* JYG: if print object is on we need to replace the base type + with rtti type in order to continue on with successful + lookup of member / method only available in the rtti type. */ + { + struct type *type = VALUE_TYPE (arg1); + struct type *real_type; + int full, top, using_enc; + + if (objectprint && + (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_CLASS)) + { + real_type = value_rtti_target_type (arg1, &full, &top, &using_enc); + if (real_type) + { + if (TYPE_CODE (type) == TYPE_CODE_PTR) + real_type = lookup_pointer_type (real_type); + else + real_type = lookup_reference_type (real_type); + + arg1 = value_cast (real_type, arg1); + } + } + } + if (noside == EVAL_AVOID_SIDE_EFFECTS) return value_zero (lookup_struct_elt_type (VALUE_TYPE (arg1), &exp->elts[pc + 2].string, Index: typeprint.c /usr/local/bin/diff -c -w -L typeprint.c typeprint.c@@/main/cygnus/6 typeprint.c *** typeprint.c --- typeprint.c Thu Mar 16 09:59:00 2000 *************** *** 82,87 **** --- 82,88 ---- register value_ptr val; register struct cleanup *old_chain = NULL; struct type *real_type = NULL; + struct type *type; int full = 0; int top = -1; int using_enc = 0; *************** *** 96,112 **** else val = access_value_history (0); real_type = value_rtti_type (val, &full, &top, &using_enc); printf_filtered ("type = "); ! if (real_type && objectprint) ! printf_filtered ("/* real type = %s%s */\n", ! TYPE_NAME (real_type), ! full ? "" : " (incomplete object)"); ! /* FIXME: maybe better to use type_print (real_type, "", gdb_stdout, -1); */ ! type_print (VALUE_TYPE (val), "", gdb_stdout, show); printf_filtered ("\n"); if (exp) --- 97,136 ---- else val = access_value_history (0); + type = VALUE_TYPE (val); + + if (objectprint) + { + if (((TYPE_CODE (type) == TYPE_CODE_PTR) || + (TYPE_CODE (type) == TYPE_CODE_REF)) + && + (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_CLASS)) + { + real_type = value_rtti_target_type (val, &full, &top, &using_enc); + if (real_type) + { + if (TYPE_CODE (type) == TYPE_CODE_PTR) + real_type = lookup_pointer_type (real_type); + else + real_type = lookup_reference_type (real_type); + } + } + else if (TYPE_CODE (type) == TYPE_CODE_CLASS) real_type = value_rtti_type (val, &full, &top, &using_enc); + } printf_filtered ("type = "); ! if (real_type) ! { ! printf_filtered ("/* real type = "); ! type_print (real_type, "", gdb_stdout, -1); ! if (! full) ! printf_filtered (" (incomplete object)"); ! printf_filtered (" */\n"); ! } ! type_print (type, "", gdb_stdout, show); printf_filtered ("\n"); if (exp) Index: valops.c /usr/local/bin/diff -c -w -L valops.c valops.c@@/main/cygnus/15 valops.c *** valops.c --- valops.c Thu Mar 16 10:01:30 2000 *************** *** 326,331 **** --- 326,337 ---- value_ptr v2 = value_ind (arg2); VALUE_ADDRESS (v2) -= VALUE_ADDRESS (v) + VALUE_OFFSET (v); + + /* JYG: adjust the new pointer value and + embedded offset. */ + v2->aligner.contents[0] -= VALUE_EMBEDDED_OFFSET (v); + VALUE_EMBEDDED_OFFSET (v2) = 0; + v2 = value_addr (v2); VALUE_TYPE (v2) = type; return v2;