[rfc, gdbserver] Disable address space randomization

[Ulrich Weigand]

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