Documentation build regressions

Documentation build regressions

[Maciej W. Rozycki]

Hi,

 I haven't run `make pdf' for a while and consequently I have only now 
noticed that it does not work anymore as TeX chokes on input.  I have 
tracked down the two offending commits to be:

commit e698b8c41cbb2648a11a2ae806922c44d1482aed
Author: Doug Evans <xdje42@gmail.com>
Date:   Tue Jun 3 00:29:49 2014 -0700

    Add command support for Guile.

for a failure in `guile.texi':

.../gdb/doc/guile.texi:1711: Unbalanced parentheses in @def.
@badparencount ...{Unbalanced parentheses in @def}
                                                  @global @parencount =0
@checkparencounts ...ount =0 @else @badparencount
                                                  @fi @ifnum @brackcount =0 ...

@printdefunline ...enalty 10002 @checkparencounts
                                                  @endgroup
l.1711 ...x? prefix@r{]} @r{[}#:doc doc-string{]})

?

and:

commit 824cc835aa9a4d585d955db4ab2a5dd4c17cc22c
Author: Phil Muldoon <pmuldoon@redhat.com>
Date:   Thu Dec 7 16:47:33 2017 +0000

    Implement explicit locations for Python breakpoints.

for a failure in `python.texi':

.../gdb/doc/python.texi:4881: Unbalanced square braces in @def.
@badbrackcount ...nbalanced square braces in @def}
                                                  @global @brackcount =0
@checkparencounts ...ount =0 @else @badbrackcount
                                                  @fi
@printdefunline ...enalty 10002 @checkparencounts
                                                  @endgroup
l.4881 ...n @r{]}, label @r{]}, line @r{]]]]]]]]})

?

The latter file and offending line has been modified since and still fails 
in a similar manner.  If I revert both files to just before the respective 
commits, then `make pdf' succeeds.  This is with:

This is pdfeTeXk, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)

You surely must have verified your changes before committing and the 
former one is especially old, so am I missing something?  I find it hard 
to believe nobody has tripped over it so far.

  Maciej

Re: Documentation build regressions

[Tom Tromey]

>>>>> "Maciej" == Maciej W Rozycki <macro@mips.com> writes:

Maciej> You surely must have verified your changes before committing and the 
Maciej> former one is especially old, so am I missing something?  I find it hard 
Maciej> to believe nobody has tripped over it so far.

FWIW I normally test doc changes with "make info" but basically never
with "make pdf".

Tom

Re: Documentation build regressions

[Jan Kratochvil]

On Wed, 30 May 2018 19:59:01 +0200, Maciej W. Rozycki wrote:
> commit 824cc835aa9a4d585d955db4ab2a5dd4c17cc22c
> Author: Phil Muldoon <pmuldoon@redhat.com>
> Date:   Thu Dec 7 16:47:33 2017 +0000
> 
>     Implement explicit locations for Python breakpoints.
> 
> for a failure in `python.texi':
> 
> .../gdb/doc/python.texi:4881: Unbalanced square braces in @def.
...
> ?

Fedora GDB builds always PDF and I have never seen such problem:
	https://kojipkgs.fedoraproject.org//packages/gdb/8.1/15.fc28/data/logs/x86_64/build.log


> This is pdfeTeXk, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)

This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) (preloaded format=pdfetex)
texlive-pdftex-20170520-29.fc28.x86_64


Jan

Re: Documentation build regressions

[Joseph Myers]

On Wed, 30 May 2018, Maciej W. Rozycki wrote:

> The latter file and offending line has been modified since and still fails 
> in a similar manner.  If I revert both files to just before the respective 
> commits, then `make pdf' succeeds.  This is with:
> 
> This is pdfeTeXk, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)

What texinfo.tex gets used?  Is it the one from the binutils-gdb source 
tree (which is over nine years old) or one from your TeX installation (and 
if the latter, which version is it)?

I suppose it's possible that sometimes one gets used and sometimes the 
other and your issue is specific to a particular texinfo.tex version.  
Another possibly relevant version is that of texi2dvi.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Documentation build regressions

[Pedro Alves]

This suggests to me that we should make the buildbot
build the documentation in its various formats.
Is that done already?  Maybe I missed it.

From a quick look at the Makefiles, maybe something around:

 make -C gdb diststuff; make -C gdb/doc all-doc pdf html

Thanks,
Pedro Alves

Re: Documentation build regressions

[Jan Kratochvil]

On Thu, 31 May 2018 19:23:31 +0200, Joseph Myers wrote:
> What texinfo.tex gets used?  Is it the one from the binutils-gdb source 
> tree (which is over nine years old) or one from your TeX installation (and 
> if the latter, which version is it)?

It is true it did not work when GDB doc build picked the shipped texinfo.tex.

So Fedora GDB now does:
	https://src.fedoraproject.org/rpms/gdb/c/fd48d313b88a8ad2cfd6f812c22279cb25467c11
	rm -rf zlib texinfo


Jan

Re: Documentation build regressions

[Joseph Myers]

On Fri, 1 Jun 2018, Jan Kratochvil wrote:

> On Thu, 31 May 2018 19:23:31 +0200, Joseph Myers wrote:
> > What texinfo.tex gets used?  Is it the one from the binutils-gdb source 
> > tree (which is over nine years old) or one from your TeX installation (and 
> > if the latter, which version is it)?
> 
> It is true it did not work when GDB doc build picked the shipped texinfo.tex.

Thanks.  In that case I advise that Maciej tries updating the shipped 
texinfo.tex to the current version - 
svn://svn.savannah.gnu.org/texinfo/trunk/doc/texinfo.tex - to see if that 
helps with the observed problem.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Documentation build regressions

[Maciej W. Rozycki]

On Fri, 1 Jun 2018, Joseph Myers wrote:

> > > What texinfo.tex gets used?  Is it the one from the binutils-gdb source 
> > > tree (which is over nine years old) or one from your TeX installation (and 
> > > if the latter, which version is it)?
> > 
> > It is true it did not work when GDB doc build picked the shipped texinfo.tex.
> 
> Thanks.  In that case I advise that Maciej tries updating the shipped 
> texinfo.tex to the current version - 
> svn://svn.savannah.gnu.org/texinfo/trunk/doc/texinfo.tex - to see if that 
> helps with the observed problem.

 Thanks for the suggestion.

 I have tried that, however that didn't change anything.  I am able to 
build `gdb.pdf' on another system though, which has:

This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian) (preloaded format=pdfetex 2018.5.30)  4 JUN 2018 20:59

so it looks to me like either triggering a bug in the old version or using 
a feature present in the new version only.  I have no strong opinion on 
whether we should require a recent enough version of TeX or if we ought to 
work with any version we might encounter.

 FWIW I have always considered TeX a pretty conservative tool and I'm 
quite surprised to see it fail in a version-dependent manner.

  Maciej

variable displayed twice when using GDB/MI

[Xavier Roirand]

Hello,

I'm using a simple C program:

void main() {
         int i=0;
}

When debugging with MI interpreter, I want to display variable i:

(gdb)
-break-insert main
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000040049b",func="main",file="foo.c",fullname="/tmp/foo.c",line="2",thread-groups=["i1"],times="0",original-location="main"}
(gdb)
-exec-run
[...]
display i
&"display i\n"
~"1: i = 0"
~"\n"
^done
(gdb)

If I do a 'next':

(gdb)
n
&"n\n"
^running
*running,thread-id="all"
(gdb)
~"1: i = 0"
~"\n"
~"3\t}\n"
~"1: i = 0"
~"\n"
[...]
(gdb)

The variable i is displayed twice, is it expected ? Using CLI 
interpreter it's displayed only once so I'm wondering if this is 
expected or not ?

Regards.

Re: variable displayed twice when using GDB/MI

[Pedro Alves]

On 06/05/2018 10:49 AM, Xavier Roirand wrote:
> Hello,
> 
> I'm using a simple C program:
> 
> void main() {
>         int i=0;
> }
> 
> When debugging with MI interpreter, I want to display variable i:
> 
> (gdb)
> -break-insert main
> ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000040049b",func="main",file="foo.c",fullname="/tmp/foo.c",line="2",thread-groups=["i1"],times="0",original-location="main"}
> (gdb)
> -exec-run
> [...]
> display i
> &"display i\n"
> ~"1: i = 0"
> ~"\n"
> ^done
> (gdb)
> 
> If I do a 'next':
> 
> (gdb)
> n
> &"n\n"
> ^running
> *running,thread-id="all"
> (gdb)
> ~"1: i = 0"
> ~"\n"
> ~"3\t}\n"
> ~"1: i = 0"
> ~"\n"
> [...]
> (gdb)
> 
> The variable i is displayed twice, is it expected ? Using CLI interpreter it's displayed only once so I'm wondering if this is expected or not ?
This is GDB printing the stop event on both the CLI uiout and on
the MI uiout, from mi_on_normal_stop_1:

      print_stop_event (mi_uiout);

      console_interp = interp_lookup (current_ui, INTERP_CONSOLE);
      if (should_print_stop_to_console (console_interp, tp))
	print_stop_event (mi->cli_uiout);

See intro comment on should_print_stop_to_console, please.

print_stop_event is what currently calls "do_displays",
so we print the displays twice.

Fixing this probably needs to take in consideration whether
we print the displays on the CLI uiout even if the stop
isn't printed there according to should_print_stop_to_console.
I.e., what makes more sense for a user that enabled some display,
but then stepped with the frontend's "step" buttons instead of
typing "next" or "step".  Probably we shouldn't print the
displays in that case, just to keep things simple, respecting
should_print_stop_to_console, but not 100% sure.

Thanks,
Pedro Alves