From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31186 invoked by alias); 30 Sep 2011 13:17:34 -0000 Received: (qmail 31165 invoked by uid 22791); 30 Sep 2011 13:17:32 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate2.uk.ibm.com (HELO mtagate2.uk.ibm.com) (194.196.100.162) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Sep 2011 13:17:17 +0000 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate2.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p8UDHFwn032326 for ; Fri, 30 Sep 2011 13:17:15 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p8UDHEw51892396 for ; Fri, 30 Sep 2011 14:17:14 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p8UDHArn023552 for ; Fri, 30 Sep 2011 07:17:10 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id p8UDH8s5023472; Fri, 30 Sep 2011 07:17:08 -0600 Message-Id: <201109301317.p8UDH8s5023472@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 30 Sep 2011 15:17:08 +0200 Subject: Re: [rfc, gdbserver] Disable address space randomization To: jan.kratochvil@redhat.com (Jan Kratochvil) Date: Fri, 30 Sep 2011 15:08:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, patches@linaro.org In-Reply-To: <20110929175714.GA18394@host1.jankratochvil.net> from "Jan Kratochvil" at Sep 29, 2011 07:57:14 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2011-09/txt/msg00572.txt.bz2 Jan Kratochvil wrote: > On Wed, 21 Sep 2011 18:23:34 +0200, Ulrich Weigand wrote: > > At this point this happens unconditionally, whenever the kernel > > supports the personality system call. If necessary, it would > > be possible to make this configurable by adding a command line > > argument to gdbserver ... > > I do not find too great it cannot be disabled. This makes inferior problems > reproducibility worse. There should be command-line option for legacy and/or > remote command for extended mode but that is obvious. > > Still it is probably better even unconditionally. Well, I can certainly add a command-line option. What would you say to e.g. --no-disable-randomization (and possibly also --disable-randomization for completeness)? I would still think gdbserver ought to default to disabling randomization, just like GDB. As to the remote command for extended mode, I'm not completely sure what the best way to trigger that from within GDB should be. Should we promote "set disable-randomization" from being a Linux-specific command to the generic level, and have its value passed to the target by remote.c? As to the protocol level, maybe we should extend vRun to take flags parameters, and make disable-randomization one of them? Or else a new QDisableRandomization packet that affects all subsequent vRun commands? There doesn't appear to be a lot of precedence regarding such flags in the remote protocol; I'd appreciate suggestions how to make this flexible for future extensions ... > > Tested on i386-linux. Fixes a couple of test failures on Ubuntu. > > I guess it has PIE by default? I am aware some PIE corner cases need more > fixes (and Fedora contains some more PIE patches even formerly posted but > those patches are not well made). I don't think PIE is related. One failure fixed by the patch is this: FAIL: gdb.mi/mi-var-cmd.exp: in-and-out-of-scope: in scope now This test always fails with randomization since it assumes two runs of the application stopping at the same place will lead to identical stack frame IDs. This is of course wrong if address space randomization affects the stack ... I seem to recall a second failure that was fixed, but I lost the logs and cannot reproduce the effect now ... this may have just been some transient failure, sorry. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com