FreeChainXenon/binutils-gdb
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

[gdb/cli] Don't let python colorize strip leading newlines

Browse source 
Consider the test-case gdb.base/async.exp.  Using the executable, I run to
main, and land on a line advertised as line 26:
...
$ gdb outputs/gdb.base/async/async -ex start
Reading symbols from outputs/gdb.base/async/async...
Temporary breakpoint 1 at 0x4004e4: file gdb.base/async.c, line 26.
Starting program: outputs/gdb.base/async/async

Temporary breakpoint 1, main () at gdb.base/async.c:26
26       y = foo ();
...

But actually, the line turns out to be line 28:
...
$ cat -n gdb.base/async.c
    ...
    26   y = 2;
    27   z = 9;
    28   y = foo ();
...

This is caused by the following: the python colorizer initializes the lexer
with default options (no second argument to get_lexer_for_filename):
...
    def colorize(filename, contents):
        # Don't want any errors.
        try:
            lexer = lexers.get_lexer_for_filename(filename)
            formatter = formatters.TerminalFormatter()
            return highlight(contents, lexer, formatter)
...
which include option stripnl=True, which strips leading and trailing newlines.

This causes the python colorizer to strip the two leading newlines of async.c.

Fix this by initializing the lexer with stripnl=False.

Build and reg-tested on x86_64-linux.

gdb/ChangeLog:

2020-04-10  Tom de Vries  <tdevries@suse.de>

	PR cli/25808
	* python/lib/gdb/__init__.py: Initialize lexer with stripnl=False.

gdb/testsuite/ChangeLog:

2020-04-10  Tom de Vries  <tdevries@suse.de>

	PR cli/25808
	* gdb.base/style.c: Add leading newlines.
	* gdb.base/style.exp: Use gdb_get_line_number to get specific lines.
	Check listing of main's one-line body.
This commit is contained in:
Tom de Vries 2020-04-10 09:29:52 +02:00
parent 6993bae074
commit bdfc1e8a0b
5 changed files with 24 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

5
gdb/ChangeLog
View file

@ -1,3 +1,8 @@
2020-04-10 Tom de Vries <tdevries@suse.de>
PR cli/25808
* python/lib/gdb/__init__.py: Initialize lexer with stripnl=False.
2020-04-09 Simon Marchi <simon.marchi@polymtl.ca>
* MAINTAINERS (Global Maintainers): Add Tom de Vries.

2
gdb/python/lib/gdb/__init__.py
View file

@ -216,7 +216,7 @@ try:
def colorize(filename, contents):
# Don't want any errors.
try:
lexer = lexers.get_lexer_for_filename(filename)
lexer = lexers.get_lexer_for_filename(filename, stripnl=False)
formatter = formatters.TerminalFormatter()
return highlight(contents, lexer, formatter)
except:

7
gdb/testsuite/ChangeLog
View file

@ -1,3 +1,10 @@
2020-04-10 Tom de Vries <tdevries@suse.de>
PR cli/25808
* gdb.base/style.c: Add leading newlines.
* gdb.base/style.exp: Use gdb_get_line_number to get specific lines.
Check listing of main's one-line body.
2020-04-08 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (psymtabs_p): New proc.

4
gdb/testsuite/gdb.base/style.c
View file

@ -1,3 +1,7 @@
/* The leading newlines here are intentional, do not remove. They are used to
test that the source highlighter doesn't strip them. */
/* Copyright 2018-2020 Free Software Foundation, Inc.
This program is free software; you can redistribute it and/or modify

8
gdb/testsuite/gdb.base/style.exp
View file

@ -39,6 +39,11 @@ save_vars { env(TERM) } {
return
}
# Check that the source highlighter has not stripped away the leading
# newlines.
set main_line [gdb_get_line_number "break here"]
gdb_test "list $main_line,$main_line" "return.*some_called_function.*"
gdb_test_no_output "set style enabled on"
set main_expr [style main function]
@ -79,8 +84,9 @@ save_vars { env(TERM) } {
}
if {$test_macros} {
set macro_line [gdb_get_line_number "\#define SOME_MACRO"]
gdb_test "info macro SOME_MACRO" \
"Defined at $base_file_expr:16\r\n#define SOME_MACRO 23"
"Defined at $base_file_expr:$macro_line\r\n#define SOME_MACRO 23"
}
set func [style some_called_function function]