Re: [patch] Disable child VMA randomizations

[Eli Zaretskii <eliz at gnu dot org>]

> Date: Sat, 7 Jun 2008 21:53:43 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> 
> the processes map their addresses randomly by default.  It can make the
> debugging inconvenient as varous addresses are different on each run.
> 
> This feature was suggested by Jakub Jelinek.  One can also already wrap whole
> GDB by a script calling: setarch `uname -m` -R

Thanks.  I have a few comments.

> +static void
> +show_disable_randomization (struct ui_file *file, int from_tty,
> +			    struct cmd_list_element *c, const char *value)
> +{
> +  fprintf_filtered (file, _("\
> +Whether we disable the randomization of the virtual address space of\n\
> +a spawned child is %s.\n"),
> +		    value);

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."

> +  add_setshow_boolean_cmd ("disable-randomization", class_support,
> +			   &disable_randomization, _("\
> +Set mode for inserting breakpoints."), _("\
> +Show mode for inserting breakpoints."), _("\

"breakpoints"?  Copy/paste error, right?

> +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?

> +Standalone programs run with the randomization enabled by default."),

On some platforms, right?

>                                                       While the addresses
> +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.

> +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.  What
are ET_DYN and ET_EXEC types? why is prelinking relevant? etc.  Again,
please explain what you are trying to say here, and why it might be
useful for readers of the manual, and I will suggest an alternative
wording.

There are also Texinfo problems in the above: the GCC command should
have the @command markup, not @code; use 3 dashes in a row, as in
"---", to produce a dash, rather than a minus sign, in the manual; and
"ranomized" is a typo.

Other than that, the patch for the manual is okay.  Thanks.