From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63793 invoked by alias); 3 Oct 2017 20:02:23 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 63783 invoked by uid 89); 3 Oct 2017 20:02:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=shelf X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Oct 2017 20:02:22 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 285ABC04AC70; Tue, 3 Oct 2017 20:02:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 285ABC04AC70 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves@redhat.com Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7A8CE4DA63; Tue, 3 Oct 2017 20:02:20 +0000 (UTC) Subject: Re: [RFC] Replicate src dir in build dir To: Yao Qi References: <1505832159-23038-1-git-send-email-yao.qi@linaro.org> <0aca31f3-4604-5630-baba-0584bb9d5c65@redhat.com> <86y3p99uy3.fsf@gmail.com> <06499c43-88b6-06cd-b3d8-4964bbd3b58e@redhat.com> <86a81djoln.fsf@gmail.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <33e5939d-b8c1-ae61-4910-7492f85fdba8@redhat.com> Date: Tue, 03 Oct 2017 20:02:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <86a81djoln.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-10/txt/msg00064.txt.bz2 On 09/29/2017 08:23 PM, Yao Qi wrote: > > I tested this patch by build gdb for each different target triplets > respectively, > > aarch64-elf aarch64-rtems aarch64-freebsd aarch64-linux alpha-elf > alpha-linux alpha-netbsd alpha-openbsd arm-elf arm-wince-pe arm-linux > arm-netbsd arm-symbianelf avr cris-elf frv-elf h8300-elf i386-elf > i386-darwin i386-dicos i386-freebsd i386-netbsdelf i386-openbsd > i386-nto i386-solaris i386-linux i386-gnu i386-cygwin i386-mingw32 > i386-go32 ia64-linux-gnu ia64-vms lm32-elf m32c-elf m32r-elf m32r-linux > m68hc11-elf m68k-elf m68k-linux m68k-netbsd m68k-openbsd m88k-openbsd > mep-elf microblaze-xilinx-elf microblaze-linux-gnu mips-elf moxie-elf > ms1-elf nios2-elf nios2-linux-gnu hppa-elf hppa-linux hppa-netbsd > hppa-openbsd powerpc-eabi powerpc-freebsd powerpc-netbsd powerpc-openbsd > powerpc-linux powerpc-lynx178 rl78-elf rx-elf s390-linux-gnu score-elf > sh-elf sh-linux sh-openbsd sh64-elf sh64-linux sh64-openbsd sparc64-linux > sparc-linux sparc-freebsd sparc64-freebsd sparc-netbsd sparc64-netbsd > sparc-openbsd sparc64-openbsd spu-elf tic6x-elf tic6x-uclinux v850-elf > vax-netbsd vax-openbsd x86_64-linux-gnu x86_64-darwin x86_64-dicos > x86_64-elf x86_64-freebsd x86_64-mingw32 x86_64-netbsd x86_64-openbsd > x86_64-rtems xstormy16-elf xtensa-elf xtensa-linux OOC, this wasn't with gdb/gdb_buildall.sh, was it? > + > +case "${targ}" in > +*-*-freebsd* | *-*-kfreebsd*-gnu) > + os_obs="fbsd-tdep.o solib-svr4.o";; > +*-*-netbsd* | *-*-knetbsd*-gnu) > + os_obs="nbsd-tdep.o solib-svr4.o";; > +*-*-openbsd*) > + os_obs="obsd-tdep.o solib-svr4.o";; I'm surprised that there's no case for GNU/Linux here, with at least linux-tdep.c and solib-svr4.o, off hand. Maybe glibc-tdep.o too. There could be a case here for mingw/cygwin ports, containing windows-tdep.o. And case for darwin ports with solib-darwin.o. But none of that are blockers. I'm totally fine with incremental progress. We can always improve on top. > +esac > + > # map target info into gdb names. I think IBWN to add a comment before each of the arch / os sections, so that it's really obvious what the different sections are about to new readers. This "map target info ..." preexisting comment just above might use an update too. But generally, I'm happy with this. Thanks much for doing it. Thanks, Pedro Alves