X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com X-Authenticated: #27081556 X-Provags-ID: V01U2FsdGVkX1+Q7BxwSt2QRHK4dr/hEnEhZ/wVyEdDs/aIGpQunj enkq8FXDhdZfG1 From: Juan Manuel Guerrero To: Eli Zaretskii Subject: Re: Difficulries with GDB 7.2 compiled with DJGPP Date: Sat, 29 Jan 2011 15:01:33 +0100 User-Agent: KMail/1.9.10 Cc: djgpp AT delorie DOT com References: <201101152018 DOT 51379 DOT juan DOT guerrero AT gmx DOT de> <201101191925 DOT 46252 DOT juan DOT guerrero AT gmx DOT de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201101291501.33886.juan.guerrero@gmx.de> X-Y-GMX-Trusted: 0 Am Donnerstag, 20. Januar 2011 schrieb Eli Zaretskii: > > From: Juan Manuel Guerrero > > Date: Wed, 19 Jan 2011 19:25:46 +0100 > > Cc: djgpp AT delorie DOT com > > > > > How come the v2.03 build avoided this issue? > > > > > > config.sub produces for an input string that contains "djgpp" the hardcoded > > output string "i586-pc-msdosdjgpp". config.guess uses uname to detect the > > processer type. This script concatenates the output produced by "uname -m" > > together with the string "pc-msdosdjgpp". The 2.04 version of uname returns > > "i786" but the 2.03 version of uname returns "i586". In those cases we get for > > the 2.04 version: i786-pc-msdosdjgpp and for > > the 2.03 version: i586-pc-msdosdjgpp. > > Can you suggest a change in config.sub that would accommodate both > v2.03 and v2.04? If so, please submit that change to config.sub > maintainers. > > Thanks. I was wrong config.[sub|guess] work as designed. The question remains if the design is good for DJGPP. The real bug is the DJGPP 2.03 port of uname. This program does not behave as it would be necessary to be usefull when used with config.[guess|sub]. config.guess uses uname to create a system ID string of the form CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM e.g.: i786-pc-msdosdjgpp. To be able to create such a string uname -m must return a usefull information. The 2.04 port of uname returns i786 but the 2.03 port of uname returns pc. This is recognized by config.guess and the DJGPP specific hardcoded string of i586-pc-msdosdjgpp is returned. This means that any DJGPP specific argument to config.guess that does not match the canonical form generates i586-pc-msdosdjgpp output string. config.sub expects as argument a string of the form CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM. If the argument matches the canonical form then the output string is identical to the argument. For the DEJGPP case, if the argument does not match the canonical form then the hardcoded string i586-pc-msdosdjgpp is returned. All this means that config.[sub|guess] have been coded completely DJGPP 2.03 centric and they will very likely fail with other DJGPP ports of uname. The reason why the build fails when DJGPP 2.04 is used is due the code copied into the Makefile template contained into /config/mh-djgpp. This is the offending part: # Shorten the target alias so when it is used to set 'libsubdir' # the name will work in both short and long filename environments. ifeq ($(findstring -pc-msdosdjgpp,$(target_alias)),-pc-msdosdjgpp) target_alias=djgpp endif When gdb is configured by running the toplevel configure script, this script cleanly identifies or the DJGPP 2.03 host/target system or the DJGPP 2.04 host/target system. config.[guess|sub] work in both cases as they should work. For DJGPP 2.03 the Makefile head contains the following lines: # ------------------------------- # Standard Autoconf-set variables # ------------------------------- VPATH=.. build_alias=i586-pc-msdosdjgpp build_vendor=pc build_os=msdosdjgpp build=i586-pc-msdosdjgpp host_alias=i586-pc-msdosdjgpp host_vendor=pc host_os=msdosdjgpp host=i586-pc-msdosdjgpp target_alias=i586-pc-msdosdjgpp target_vendor=pc target_os=msdosdjgpp target=i586-pc-msdosdjgpp For DJGPP 2.04 the Makefile head contains the following lines: # ------------------------------- # Standard Autoconf-set variables # ------------------------------- VPATH=.. build_alias=i786-pc-msdosdjgpp build_vendor=pc build_os=msdosdjgpp build=i786-pc-msdosdjgpp host_alias=i786-pc-msdosdjgpp host_vendor=pc host_os=msdosdjgpp host=i786-pc-msdosdjgpp target_alias=i786-pc-msdosdjgpp target_vendor=pc target_os=msdosdjgpp target=i786-pc-msdosdjgpp As can be seen in both cases everthing is OK because build_alias = host_alias = target_alias. This means that a native debugger should be compiled. Unfortunately the mh-djgpp file changes the target_alias to djgpp. This value is passed to the configure scripts of the different directories and they pass "djgpp" as argument to config.sub. config.sub returns as target_alias always i586-pc-msdosdjgpp if its input argument was "djgpp". This always works for DJGPP 2.03 because it matches the output produced by config.guess with uname version produced with DJGPP 2.03; but it fails for any other DJGPP version of uname. Although my initial assumption that config[guess|sub] were brocken was wrong, the patch I have applied to config.sub DTRT. Neitherless probably the rigth place to fix this is the /config/mh-djgpp file. That file is very old and I think it should be adapted by the author. OFYI, below the small patch to config.sub, to get it working with all versions of uname. Regards, Juan M. Guerrero diff -aprNU5 gdb-7.2.orig/config.sub gdb-7.2/config.sub --- gdb-7.2.orig/config.sub 2010-06-01 17:53:40 +0000 +++ gdb-7.2/config.sub 2011-01-22 23:28:54 +0000 @@ -579,11 +579,19 @@ case $basic_machine in dicos) basic_machine=i686-pc os=-dicos ;; djgpp) - basic_machine=i586-pc + UNAME_MACHINE=`(uname -m) 2>/dev/null` || UNAME_MACHINE=unknown + case $UNAME_MACHINE in + *386*) basic_machine=i386-pc;; + *486*) basic_machine=i486-pc;; + *586*) basic_machine=i586-pc;; + *686*) basic_machine=i686-pc;; + *786*) basic_machine=i786-pc;; + *) basic_machine=i586-pc;; + esac os=-msdosdjgpp ;; dpx20 | dpx20-*) basic_machine=rs6000-bull os=-bosx