From: Eli Zaretskii <eliz@gnu.org>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch#2 2/6] set auto-load * main part
Date: Thu, 05 Apr 2012 16:11:00 -0000 [thread overview]
Message-ID: <83vcleb1lb.fsf@gnu.org> (raw)
In-Reply-To: <20120403183301.GA13483@host2.jankratochvil.net>
> Date: Tue, 3 Apr 2012 20:33:01 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb-patches@sourceware.org
>
> > > +@node Auto-loading
> > > +@section Automatically loading associated files
> >
> > "@cindex auto-loading" would be good here.
>
> Done. Therefore also changed now:
> @node Python Auto-loading
> @subsection Python Auto-loading
> @cindex auto-loading, Python
> ->
> @cindex Python auto-loading, Python
Do we really need "Python" twice?
> > I suggest "... to prevent @value{GDBN} from reading any auto-loaded files"
> > instead.
>
> I think the meaning is not right now.
>
> There are three categories of files:
>
> 1. /etc/gdbinit (system gdbinit) and ~/.gdbinit:
> They can be disabled only by -nx.
> 2. Current directory .gdbinit
> They can be disabled either by -nx or by 'set auto-load local-gdbinit no'.
> 3. Files like objfile-gdb.py or libthread_db.so.1
> These can be disabled only by 'set auto-load no' (or more specific variants).
>
> There exists currently no 'set auto-load system-gdbinit'
> or 'set auto-load home-gdbinit' so the option -nx still needs to be used in
> some cases.
>
> Using -nx will not disable for example the objfile-gdb.py loading.
>
> The current paragraph
>
> # Be aware that system init file (@pxref{System-wide configuration})
> # and init files from your home directory (@pxref{Home Directory Init File})
> # still get read still get read (as they come from generally trusted
> # directories). You could use also the @ref{-nx} option to prevent @value{GDBN}
> # from reading any auto-loaded files instead.
>
> IMO says that -nx will disable even objfile-gdb.py, libthread_db.so.1 etc.
> auto-loading. Or at least it is ambiguous in such way.
Point taken, but then what _did_ you mean by "very every"?
>
>
> > > +@smallexample
> > > +(gdb) info auto-load
> > > +gdb-scripts: Loaded Script
> > > +Yes /home/user/gdb/gdb-gdb.rc
> >
> > This is a strange layout, and I'm quite sure it will look wrong in
> > Info (as the trailing whitespace won't do what you think). Can you
> > show how this display is supposed to look like on the screen?
>
> The trailing spaces are fixed now. (Trailing spaces appear in GDB output in
> general but that is really outside of the scope of this patchset.)
>
> The table header was not properly aligned for "info auto-load" while it was
> right for the specific commands like "info auto-load gdb-scripts". The code is
> no longer much nice (introduced there #define INFO_AUTO_LOAD hack) but I agree
> the layout looks much better now.
>
> Fixed therefore also the doc:
>
> @smallexample
> (gdb) info auto-load
> gdb-scripts:
> Loaded Script
> Yes /home/user/gdb/gdb-gdb.gdb
> libthread-db: No auto-loaded libthread-db.
> local-gdbinit: Local .gdbinit file "/home/user/gdb/.gdbinit" has been loaded.
> python-scripts:
> Loaded Script
> Yes /home/user/gdb/gdb-gdb.py
> @end smallexample
>
>
> > > +@multitable {@xref{dotdebug_gdb_scripts section}.} {See @ref{set auto-load python-scripts}}
> > > +@item @xref{objfile-gdb.py file}.
> > > +@tab See @ref{set auto-load python-scripts}.
> >
> > Does this table with 2 cross-references on each line look good in the
> > Info manual?
>
> IMO it looks great:
>
> *Note objfile-gdb.py file::. See *note set auto-load python-scripts::.
> *Note objfile-gdb.gdb file::. See *note set auto-load gdb-scripts::.
> *Note dotdebug_gdb_scripts section::. See *note set auto-load python-scripts::.
> *Note Current Directory Init File::. See *note set auto-load local-gdbinit::.
> *Note libthread_db.so.1 file::. See *note set auto-load libthread-db::.
>
> That "Note" and "note" are excessive there but I could not get rid of them.
> I wanted to have there something like @menu but @menu is very special and
> I cannot have arbitrary number of @menus inside the @node, moreover to
> reference arbitrary @nodes in the document. So I found @multitable to be the
> most close to @menu one can get.
>
> It looks even slightly better in PDF.
OK, fine with me.
next prev parent reply other threads:[~2012-04-05 16:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-29 9:12 Jan Kratochvil
2012-03-30 7:20 ` Eli Zaretskii
2012-04-03 18:33 ` Jan Kratochvil
2012-04-05 16:11 ` Eli Zaretskii [this message]
2012-04-05 18:25 ` Jan Kratochvil
2012-04-05 21:20 ` Eli Zaretskii
2012-04-05 21:28 ` Eli Zaretskii
2012-04-05 21:33 ` Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83vcleb1lb.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox