On Sat, 07 Jun 2008 22:41:09 +0200, Andreas Schwab wrote:
...
> This is underquoted.  All arguments containing nested macro invocations
> should be quoted.

Fixed, thanks.


On Sat, 07 Jun 2008 22:42:42 +0200, Eli Zaretskii wrote:
...
> That longish sentence could be made both shorter and more clear.  How
> about this one:
> 
>   "Disabling randomization of debuggee's virtual address space is %s."

Used your wording.


> "breakpoints"?  Copy/paste error, right?

Fixed.

+Set disabling of debuggee's virtual address space randomization."), _("\
+Show disabling of debuggee's virtual address space randomization."), _("\


> > +When this mode is on (which is the default), the randomization of\n\
> > +the virtual address space is disabled (turns on ADDR_NO_RANDOMIZE).\n\
>                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^
> What is this supposed to tell Joe Random Hacker who uses GDB to debug
> his/her program?  What is ADDR_NO_RANDOMIZE?

ctags will find him /usr/include/linux/personality.h:
        ADDR_NO_RANDOMIZE =     0x0040000,      /* disable randomization of VA space */

Removed my whole text in brackets.


> > +Standalone programs run with the randomization enabled by default."),
> 
> On some platforms, right?

Fixed.

Standalone programs run with the\n\
+randomization enabled by default on the GNU/Linux platform."),


> > +get assigned differently on each run some subtle bugs may be reproducible only
> > +with specially assigned addresses possibly not reachable with the default
> > +setting of @kbd{set disable-randomization on}.
> 
> Can you explain this sentence?  I'd like to suggest a better wording,
> but I can't do that unless I understand what is it that you are trying
> to say here.

New text:

As some debuggee's
+bugs may depend on the assigned addresses the default @value{GDBN} behavior of
+disabling the randomization may make some debuggee's bugs unreproducible.  You
+may want to run the debuggee many times with the randomization enabled (and
+thus this option disabled) to catch such kind of bugs.  Correctly written
+programs must run the same way notwithstanding this configuration option.


I do not know about such a bug example off hand but sure there can be such one
created (such as not expecting \x00 in an adress which would never
coincidentally happen when the randomization is disabled - although 0x00 is
more expected with the randomization disabled as the addresses are then lower).


> > +PIE executables (type @code{ET_DYN}, compiled by @code{gcc -fPIE -pie}) have
> > +randomized everything - the executable base address, shared libraries base
> > +address (their prelinking is ignored), mmap areas, stack and heap.  Regular
> > +executables (type @code{ET_EXEC}) do not have randomized their base address,
> > +shared libraries base address is ranomized only for non-prelinked libraries,
> > +mmap, stack and heap are still randomized.
> 
> There's too much unexplained technical details here, so much so that
> this paragraph sounds like it was meant only for the initiated.

It is mostly explained at:
	http://lwn.net/Articles/190139/

I expected the full explanation is inappropriate for the GDB manual but I tried
to include it in this patch:

+The virtual address space randomization is implemented only on @sc{gnu}/Linux.
+It protects the programs against some kinds of security attacks.  In these
+cases the attacker needs to know the exact location of a concrete executable
+code.  Randomizing its location makes it impossible to inject jumps misusing
+a code at its expected addresses.
+
+Prelinking shared libraries provides a startup performance advantage but it
+makes addresses in these libraries predictable for privileged processes by
+having just unprivileged access at the target system.  Reading the shared
+library binary gives enough information for assembling the malicious code
+misusing it.  Still even a prelinked shared library can get loaded a a new
+random address just requiring the regular relocation process during the
+startup.  Shared libraries not already prelinked are always loaded at
+a randomly chosen address.
+
+Position independent executables (PIE) contain position independent code
+similar to the shared libraries and therefore such executables get loaded at
+a randomly chosen address upon startup.  PIE executables always load even
+already prelinked shared libraries at a random address.  You can build such
+executable using @command{gcc -fPIE -pie}.
+
+Heap (malloc storage), stack and custom mmap areas are always placed randomly
+(as long as the randomization is enabled).


> and "ranomized" is a typo.

Fixed, spell-checked this time.


Thanks for the doc review.

(Patch now additionally prefers the system definition of ADDR_NO_RANDOMIZE.)


Regards,
Jan