From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23012 invoked by alias); 12 Dec 2014 14:38:17 -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 23002 invoked by uid 89); 12 Dec 2014 14:38:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 12 Dec 2014 14:38:15 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBCEcEQp031063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 12 Dec 2014 09:38:14 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sBCEcC8C030260; Fri, 12 Dec 2014 09:38:13 -0500 Message-ID: <548AFDD4.70501@redhat.com> Date: Fri, 12 Dec 2014 14:38:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jan Kratochvil CC: gdb-patches@sourceware.org Subject: Re: [PATCH v3 14/14] the "compile" command References: <20141101214552.13230.45564.stgit@host1.jankratochvil.net> <20141101214733.13230.49968.stgit@host1.jankratochvil.net> <54625B26.8000309@redhat.com> <20141123183644.GA31165@host2.jankratochvil.net> In-Reply-To: <20141123183644.GA31165@host2.jankratochvil.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-12/txt/msg00283.txt.bz2 On 11/23/2014 06:36 PM, Jan Kratochvil wrote: > On Tue, 11 Nov 2014 19:53:26 +0100, Pedro Alves wrote: >>> +/* See compile-internal.h. */ >>> + >>> +void >>> +gcc_convert_symbol (void *datum, >>> + struct gcc_c_context *gcc_context, >>> + enum gcc_c_oracle_request request, >>> + const char *identifier) >> >> ... >> >>> + >>> + /* We can't allow exceptions to escape out of this callback. Safest >>> + is to simply emit a gcc error. */ >>> + TRY_CATCH (e, RETURN_MASK_ERROR) >>> + { >>> + struct symbol *sym; >> >> Shouldn't this catch ctrl-c too then? Likewise the other hooks. > > Yes, changed. > > >>> + for (i = 0; i < 4; ++i) >> >> It'd be good to give this magic constant a name, or at >> a least a comment. > > Added there: > // Iterate all log2 sizes in bytes supported by c_get_mode_for_size. > Added to c_get_mode_for_size: > default: > internal_error (__FILE__, __LINE__, _("Invalid GCC mode size %d."), size); > > >>> + { >>> + const char *mode = c_get_mode_for_size (1 << i); >>> + >>> + gdb_assert (mode != NULL); >>> + fprintf_unfiltered (buf, >>> + "typedef int" >>> + " __attribute__ ((__mode__(__%s__)))" >>> + " __gdb_int_%s;\n", >>> + mode, mode); >>> + } >> >> >> >>> + >>> +/* A cleanup function to remove a directory and all its contents. */ >>> + >>> +static void >>> +do_rmdir (void *arg) >>> +{ >>> + char *zap = concat ("rm -rf ", arg, (char *) NULL); >>> + >>> + system (zap); >>> +} >> >> This is quite scary... Could we please add an assert here >> that tempdir_name starts with "/tmp/gdbobj-", just in case something >> goes really wrong here? > > Added: > /* Initial filename for temporary files. */ > > #define TMP_PREFIX "/tmp/gdbobj-" > + > #define TEMPLATE TMP_PREFIX "XXXXXX" > + > gdb_assert (strncmp (dir, TMP_PREFIX, strlen (TMP_PREFIX)) == 0); > > >>> + /* Override flags possibly coming from DW_AT_producer. */ >>> + compile_args = xstrdup ("-O0 -gdwarf-4" >>> + /* We use -fPIC to ensure that we can reference properly. Otherwise >>> + on x86-64 a string constant's address might be truncated when gdb >>> + loads the object; another approach would be -mcmodel=large, but >>> + -fPIC seems more portable across back ends. */ >> >> This comment ends up being a bit unexpected/odd, given that ... >> >>> + " -fPIC" >>> + /* We don't want warnings. */ >>> + " -w" >> >> ... patch #6 has: >> >>> +char * >>> +default_gcc_target_options (struct gdbarch *gdbarch) >>> +{ >>> + return xstrprintf ("-m%d%s", gdbarch_ptr_bit (gdbarch), >>> + gdbarch_ptr_bit (gdbarch) == 64 ? " -mcmodel=large" : ""); >>> +} >>> + >> >> IOW, is the comment stale? > > You are right the comment is stale although the code is not stale. Up to date > reason for these options I have written in: > https://sourceware.org/gdb/wiki/GCCCompileAndExecute#Relocating_the_object_file > Therefore put there: > /* We use -fPIC Otherwise GDB would need to reserve space large enough for > any object file in the inferior in advance to get the final address when > to link the object file to and additionally the default system linker > script would need to be modified so that one can specify there the > absolute target address. */ > " -fPIC" > And also: > /* -mcmodel=large is used so that no GOT (Global Offset Table) is needed to be > created in inferior memory by GDB (normally it is set by ld.so). */ > > char * > default_gcc_target_options (struct gdbarch *gdbarch) > { > return xstrprintf ("-m%d%s", gdbarch_ptr_bit (gdbarch), > gdbarch_ptr_bit (gdbarch) == 64 ? " -mcmodel=large" : ""); > } > Thanks Jan. I'm happy with these changes. Thanks, Pedro Alves