From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Bambrough To: Andrew Cagney Cc: GDB Patches Mail List Subject: Re: RFC: changes to configure.in and configure Date: Tue, 01 Aug 2000 07:38:00 -0000 Message-id: <3986DF7C.FCDD8A65@netwinder.org> References: <3985A85C.C246C623@netwinder.org> <39863CD3.A527CEC3@cygnus.com> X-SW-Source: 2000-08/msg00007.html Andrew Cagney wrote: > > I'm not sure how this patch: > > -# else > +else > # GDBserver is only useful in a "native" enviroment > -# configdirs=`echo $configdirs | sed 's/gdbserver//'` > +configdirs=`echo $configdirs | sed 's/gdbserver//'` > fi > changequote([,]) This bit of the patch removes gdbserver from $configdirs unless it is a native build. > +SUBDIRS="doc testsuite nlm $configdirs" > +if test "${enable_multi_ice}" = "yes"; then > + SUBDIRS="${SUBDIRS} multi-ice" > +fi > + > +AC_SUBST(SUBDIRS) > changes things. Hmmmmm, ah this bit: > > has something to do with it - be careful to not re-order code > unnecessarily - it can hide real changes. Yes, this is the effective part of the change. I didn't reorder the code unnecessarily. This was all together in configure.in until someone added code in between, the day before I submitted my patch. I wonder who that was :) ? > o not build gdbserver > (suprize!) > > o always configure GDBSERVER > (when selected) > > Your change would completly reverse this. I don't know that that was > the intention. It doesn't happen. gdbserver never gets configured without explicitly going into the directory and configuring. AFAIK, a target maintainer can select gdbserver by modifying $configdirs in configure.tgt. It can also add other directories to configure. This seems to be the way gdbserver is selected and built. It is also the way the arm embedded targets select rdi-share to be configured and the netware targets select nlm to be configured. Whoever made this change broke this mechanism, while trying to prevent gdbserver from being built. It would be better to add --enable-gdbserver and --disable-gdbserver flags IMHO if you wanted to selectively build gdbserver. What do you think? Scott -- Scott Bambrough - Software Engineer REBEL.COM http://www.rebel.com NetWinder http://www.netwinder.org >From msnyder@redhat.com Tue Aug 01 08:04:00 2000 From: Michael Snyder To: Scott Bambrough Cc: Andrew Cagney , GDB Patches Mail List Subject: Re: RFC: changes to configure.in and configure Date: Tue, 01 Aug 2000 08:04:00 -0000 Message-id: <3986E6A3.6B3C@redhat.com> References: <3985A85C.C246C623@netwinder.org> <39863CD3.A527CEC3@cygnus.com> <3986DF7C.FCDD8A65@netwinder.org> X-SW-Source: 2000-08/msg00008.html Content-length: 467 Scott Bambrough wrote: > > Andrew Cagney wrote: > > > > I'm not sure how this patch: > > > > -# else > > +else > > # GDBserver is only useful in a "native" enviroment > > -# configdirs=`echo $configdirs | sed 's/gdbserver//'` > > +configdirs=`echo $configdirs | sed 's/gdbserver//'` > > fi > > changequote([,]) > > This bit of the patch removes gdbserver from $configdirs unless it is a native > build. Why? What about host-x-host? What about embedded linux? >From scottb@netwinder.org Tue Aug 01 08:37:00 2000 From: Scott Bambrough To: msnyder@redhat.com Cc: Andrew Cagney , GDB Patches Mail List Subject: Re: RFC: changes to configure.in and configure Date: Tue, 01 Aug 2000 08:37:00 -0000 Message-id: <3986ED4C.908168DA@netwinder.org> References: <3985A85C.C246C623@netwinder.org> <39863CD3.A527CEC3@cygnus.com> <3986DF7C.FCDD8A65@netwinder.org> <3986E6A3.6B3C@redhat.com> X-SW-Source: 2000-08/msg00009.html Content-length: 869 Michael Snyder wrote: > > Scott Bambrough wrote: > > > > This bit of the patch removes gdbserver from $configdirs unless it is a native > > build. > > Why? What about host-x-host? What about embedded linux? This is why: "Configuring gdbserver you should specify the same machine for host and target (which are the machine that gdbserver is going to run on. This is not the same as the machine that gdb is going to run on; building gdbserver automatically as part of building a whole tree of tools does not currently work if cross-compilation is involved (we don't get the right CC in the Makefile, to start with))." This is a quote, from the README in the gdbserver directory. It is the reason I re-enabled that part of the configure code. Scott -- Scott Bambrough - Software Engineer REBEL.COM http://www.rebel.com NetWinder http://www.netwinder.org >From taylor@cygnus.com Tue Aug 01 08:54:00 2000 From: David Taylor To: Andrew Cagney Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [BUG] print_address_numeric Date: Tue, 01 Aug 2000 08:54:00 -0000 Message-id: <200008011554.LAA02265@texas.cygnus.com> X-SW-Source: 2000-08/msg00010.html Content-length: 4526 Date: Tue, 01 Aug 2000 12:28:42 +1000 From: Andrew Cagney David Taylor wrote: > > In printcmd.c (print_address_numeric), we find the lines: > > int ptr_bit = TARGET_PTR_BIT; > if (ptr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT)) > addr &= ((CORE_ADDR) 1 << ptr_bit) - 1; > print_longest (stream, 'x', use_local, (ULONGEST) addr); You forgot the lines: /* Truncate address to the size of a target pointer, avoiding shifts larger or equal than the width of a CORE_ADDR. The local variable PTR_BIT stops the compiler reporting a shift overflow when it won't occure. */ /* NOTE: This assumes that the significant address information is kept in the least significant bits of ADDR - the upper bits were either zero or sign extended. Should ADDRESS_TO_POINTER() or some ADDRESS_TO_PRINTABLE() be used to do the conversion? */ :-) Well, those lines didn't change. With regard to the question: "Should ADDRESS_TO_POINTER() or some ADDRESS_TO_PRINTABLE() be used to do the conversion?" ADDRESS_TO_POINTER -- no; ADDRESS_TO_PRINTABLE -- sure, but I don't need it. > This code has a bug, namely it assumes that addresses and pointers are > the same size. > > [address == gdb representation; pointer == target representation] CORE_ADDR - GDB's internal representation of an address it is large enough to fit target address information. pointer - targets pointer representation ??? - minimum number of bits needed to represent an address on the target. Currently, TARGET_PTR_BIT says how many bits pointers take in the target representation; there is no macro / gdbarch field to say how many bits addresses take within CORE_ADDR. My proposed TARGET_ADDR_BIT / addr_bit is to add just such a macro / field -- with the default value being the value of TARGET_PTR_BIT / ptr_bit, so that targets that do nothing will work as they do now. When printing a symbolic address, should it be displayed using GDB's internal format (for MIPS definitly not) or target pointer format. Currently, it does neither properly. It takes the GDB representation, and prints the number of bits that are significant on the target. For a Harvard architecture chip, it's nice to be able to tell from the value which address space it lives in. For example, for the chip I'm working on, instruction memory (on the target) is word addressed, not byte addressed. On the target, the first instruction is at address 0, the next at address 1, the following at address 2, and so on. In gdb, the first instruction is at address 0x2000000, the next at 0x2000002, the following at 0x2000004, and so on. If you set a breakpoint at 0x2000004, it will tell you it set it at address 0x4. I feel that it should either say 0x2000004 ('cause that is what address the user has to give to set a breakpoint there) or 0x2 ('cause that is what address the target considers it to be). And of the two, I feel that it should report an address that the user would type in, namely the gdb representation, which would be 0x2000004 in this case. Additionally, it's name suggests that it is printing an address, not a pointer (print_address_numeric). And, at least in my case, it is being given an address (b->address), not a pointer. > For some processors they are different. For the d10v and at least one > other processor, the size of a pointer is 2 bytes, but the size of an > address is 4 bytes. > > I propose the creation of a new macro TARGET_ADDR_BIT, the addition of > the lines: > > #if !defined(TARGET_ADDR_BIT) > #define TARGET_ADDR_BIT TARGET_PTR_BIT > #endif > > to defs.h, and that the above lines of print_address_numeric be changed to: > > int addr_bit = TARGET_ADDR_BIT > if (addr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT)) > addr & ((CORE_ADDR) 1 << ptr_bit) - 1; > print_longest (stream, 'x', use_local, (ULONGEST) addr); > > Comments? I think it should be a method (function) rather than a macro. The default function using TARGET_PTR_BIT. It would give your target complete freedom over how the numeric address is printed. Andrew I have no objection to having a method (function) *in addition* to the macro TARGET_ADDR_BIT. But, I feel that the macro should be created and that print_address_numeric should use it. >From fnasser@cygnus.com Tue Aug 01 08:55:00 2000 From: Fernando Nasser To: Jimmy Guo Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] dejagnu runtest.exp cleanup Date: Tue, 01 Aug 2000 08:55:00 -0000 Message-id: <3986F211.3E40C5C5@cygnus.com> References: X-SW-Source: 2000-08/msg00011.html Content-length: 2107 Jimmy, It is sort of standard in the current dejagnu code to look for an environment variable if the variable is not defined. Is there a specific reason why you want to remove it (like, it is conflicting with some environment variable that is frequently defined on HP)? Can't we just leave it there for the sake of code coherence? Thanks, F. Jimmy Guo wrote: > > Mon Jul 31 16:45:29 Jimmy Guo > > * runtest.exp: Cleanup reference to $env(MULTIPASS) and > $env(PASS). These were added by HP but unused since. > > Index: runtest.exp > /usr/local/bin/diff -c -L runtest.exp runtest.exp@@/main/cygnus/6 runtest.exp > *** runtest.exp > --- runtest.exp Mon Jul 31 16:43:59 2000 > *************** > *** 1604,1623 **** > > if { [info exists MULTIPASS] } { > set multipass $MULTIPASS > - } elseif {[info exists env(MULTIPASS)]} { > - set multipass $env(MULTIPASS) > } > if { $multipass == "" } { > set multipass { "" } > } > > ! # If PASS is specified, either as a TCL variable or in environment, we > ! # want to run only the tests specified. Its value should be a number > ! # or a list of numbers that specify the passes that we want to run. > if [info exists PASS] { > set pass $PASS > - } elseif [info exists env(PASS)] { > - set pass $env(PASS) > } else { > set pass "" > } > --- 1604,1619 ---- > > if { [info exists MULTIPASS] } { > set multipass $MULTIPASS > } > if { $multipass == "" } { > set multipass { "" } > } > > ! # If PASS is specified, we want to run only the tests specified. > ! # Its value should be a number or a list of numbers that specify > ! # the passes that we want to run. > if [info exists PASS] { > set pass $PASS > } else { > set pass "" > } -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From fnasser@cygnus.com Tue Aug 01 08:56:00 2000 From: Fernando Nasser To: Jimmy Guo Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] dejagnu runtest.exp misc. fixes Date: Tue, 01 Aug 2000 08:56:00 -0000 Message-id: <3986F310.1498E68B@cygnus.com> References: X-SW-Source: 2000-08/msg00012.html Content-length: 3658 Jimmy, Can you elaborate on how one would use this. What happens today and what will happen after this change? Can you give an example, please? Thanks, F. Jimmy Guo wrote: > > Mon Jul 31 16:54:52 Jimmy Guo > > * runtest.exp: Handle multiple directories in TCL variables > dir_to_run and cmdline_dir_to_run; limit *.exp find to > one directory level to avoid foo/bar/baz.exp getting tested > twice (when ${dir} is 'foo', and when ${dir} is 'foo/bar'). > > Index: runtest.exp > /usr/local/bin/diff -c -L runtest.exp runtest.exp@@/main/cygnus/6 runtest.exp > *** runtest.exp > --- runtest.exp Mon Jul 31 16:54:33 2000 > *************** > *** 1734,1740 **** > # value (for example in MULTIPASS) and the test > # directory matches that directory. > if {[info exists dir_to_run] && $dir_to_run != ""} { > ! if ![string match "*${dir_to_run}*" $dir] { > continue > } > } > --- 1734,1747 ---- > # value (for example in MULTIPASS) and the test > # directory matches that directory. > if {[info exists dir_to_run] && $dir_to_run != ""} { > ! set found 0 > ! foreach directory $dir_to_run { > ! if [string match "*${directory}*" $dir] { > ! set found 1 > ! break > ! } > ! } > ! if {!$found} { > continue > } > } > *************** > *** 1744,1755 **** > # directory matches that directory > if {[info exists cmdline_dir_to_run] \ > && $cmdline_dir_to_run != ""} { > ! if ![string match "*${cmdline_dir_to_run}*" $dir] { > continue > } > } > > ! foreach test_name [lsort [find ${dir} *.exp]] { > if { ${test_name} == "" } { > continue > } > --- 1751,1772 ---- > # directory matches that directory > if {[info exists cmdline_dir_to_run] \ > && $cmdline_dir_to_run != ""} { > ! set found 0 > ! foreach directory $cmdline_dir_to_run { > ! if [string match "*${directory}*" $dir] { > ! set found 1 > ! break > ! } > ! } > ! if {!$found} { > continue > } > } > > ! # JYG: Limit find to one level, since we don't want > ! # to pick up foo/bar/baz.exp twice ... > ! # ${test_top_dirs} includes '... foo/ foo/bar/ ...' > ! foreach test_name [lsort [find -maxdepth 1 ${dir} *.exp]] { > if { ${test_name} == "" } { > continue > } -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From guo@cup.hp.com Tue Aug 01 09:35:00 2000 From: Jimmy Guo To: Fernando Nasser Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] dejagnu runtest.exp cleanup Date: Tue, 01 Aug 2000 09:35:00 -0000 Message-id: References: <3986F211.3E40C5C5@cygnus.com> X-SW-Source: 2000-08/msg00013.html Content-length: 2504 Well some of the env variables were added by HP ... and we have since moved to use the site.exp TCL var interface, after I learned that the env var interface might interfere with the standard build process (e.g. gnu make). I'm not too strong on this ... if you think keeping these env vars around is OK, that fine as well. - Jimmy Guo >It is sort of standard in the current dejagnu code to look for an environment variable >if the variable is not defined. Is there a specific reason why you want to remove it >(like, it is conflicting with some environment variable that is frequently defined on HP)? > >Can't we just leave it there for the sake of code coherence? > >Thanks, >F. > > >Jimmy Guo wrote: >> >> Mon Jul 31 16:45:29 Jimmy Guo >> >> * runtest.exp: Cleanup reference to $env(MULTIPASS) and >> $env(PASS). These were added by HP but unused since. >> >> Index: runtest.exp >> /usr/local/bin/diff -c -L runtest.exp runtest.exp@@/main/cygnus/6 runtest.exp >> *** runtest.exp >> --- runtest.exp Mon Jul 31 16:43:59 2000 >> *************** >> *** 1604,1623 **** >> >> if { [info exists MULTIPASS] } { >> set multipass $MULTIPASS >> - } elseif {[info exists env(MULTIPASS)]} { >> - set multipass $env(MULTIPASS) >> } >> if { $multipass == "" } { >> set multipass { "" } >> } >> >> ! # If PASS is specified, either as a TCL variable or in environment, we >> ! # want to run only the tests specified. Its value should be a number >> ! # or a list of numbers that specify the passes that we want to run. >> if [info exists PASS] { >> set pass $PASS >> - } elseif [info exists env(PASS)] { >> - set pass $env(PASS) >> } else { >> set pass "" >> } >> --- 1604,1619 ---- >> >> if { [info exists MULTIPASS] } { >> set multipass $MULTIPASS >> } >> if { $multipass == "" } { >> set multipass { "" } >> } >> >> ! # If PASS is specified, we want to run only the tests specified. >> ! # Its value should be a number or a list of numbers that specify >> ! # the passes that we want to run. >> if [info exists PASS] { >> set pass $PASS >> } else { >> set pass "" >> } > >-- >Fernando Nasser >Red Hat Canada Ltd. E-Mail: fnasser@cygnus.com >2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 >Toronto, Ontario M4P 2C9 Fax: 416-482-6299