Re: Next command of GDB does not work properly unusual

2018-07-12 Thread YASUOKA Masahiko


On Thu, 12 Jul 2018 19:14:19 +0900 (JST)
YASUOKA Masahiko  wrote:
>> On 2018/07/12 16:16, YASUOKA Masahiko wrote:
>>> > The next command of GDB does not work properly.
>>> > I use OpenBSD 6.3 and /usr/bin/gdb (GDB 6.3).
>>> 
>>> It seems that gdb can't read the dwarf generated by clang properly.

Then, how about using the diff from asou?

Index: gnu/usr.bin/binutils/gdb/dwarf2read.c
===
RCS file: /cvs/src/gnu/usr.bin/binutils/gdb/dwarf2read.c,v
retrieving revision 1.5
diff -u -p -r1.5 dwarf2read.c
--- gnu/usr.bin/binutils/gdb/dwarf2read.c   27 Dec 2004 21:05:10 -  
1.5
+++ gnu/usr.bin/binutils/gdb/dwarf2read.c   12 Jul 2018 10:42:59 -
@@ -6479,7 +6479,7 @@ dwarf_decode_lines (struct line_header *
* lh->minimum_instruction_length;
  line += lh->line_base + (adj_opcode % lh->line_range);
   lh->file_names[file - 1].included_p = 1;
-  if (!decode_for_pst_p)
+  if (!decode_for_pst_p && line != 0)
 {
  /* Append row to matrix using current values.  */
  record_line (current_subfile, line, 


On Thu, 12 Jul 2018 19:14:19 +0900 (JST)
YASUOKA Masahiko  wrote:
> On Thu, 12 Jul 2018 10:37:33 +0100
> Stuart Henderson  wrote:
>> On 2018/07/12 16:16, YASUOKA Masahiko wrote:
>>> > The next command of GDB does not work properly.
>>> > I use OpenBSD 6.3 and /usr/bin/gdb (GDB 6.3).
>>> 
>>> It seems that gdb can't read the dwarf generated by clang properly.
>>> I found a better fix at the upstream.
>>> 
>>>
>>> https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=ca5f395d6255337974262b4a6f40da531fcf6204
>>> 
>>> ok?
>> 
>> I believe that is a post-GPLv3 commit..
> 
> Indeed...
> 
>>> Index: gnu/usr.bin/binutils/gdb/dwarf2read.c
>>> ===
>>> RCS file: /var/cvs/openbsd/src/gnu/usr.bin/binutils/gdb/dwarf2read.c,v
>>> retrieving revision 1.5
>>> diff -u -p -r1.5 dwarf2read.c
>>> --- gnu/usr.bin/binutils/gdb/dwarf2read.c   27 Dec 2004 21:05:10 -  
>>> 1.5
>>> +++ gnu/usr.bin/binutils/gdb/dwarf2read.c   12 Jul 2018 07:07:57 -
>>> @@ -6479,13 +6479,13 @@ dwarf_decode_lines (struct line_header *
>>> * lh->minimum_instruction_length;
>>>   line += lh->line_base + (adj_opcode % lh->line_range);
>>>lh->file_names[file - 1].included_p = 1;
>>> -  if (!decode_for_pst_p)
>>> +  if (!decode_for_pst_p && is_stmt)
>>>  {
>>>   /* Append row to matrix using current values.  */
>>>   record_line (current_subfile, line, 
>>>check_cu_functions (address, cu));
>>>  }
>>> - basic_block = 1;
>>> + basic_block = 0;
>>> }
>>>   else switch (op_code)
>>> {
>>> @@ -6499,7 +6499,7 @@ dwarf_decode_lines (struct line_header *
>>> case DW_LNE_end_sequence:
>>>   end_sequence = 1;
>>>lh->file_names[file - 1].included_p = 1;
>>> -  if (!decode_for_pst_p)
>>> +  if (!decode_for_pst_p && is_stmt)
>>> record_line (current_subfile, 0, address);
>>>   break;
>>> case DW_LNE_set_address:
>>> 
>>> On Thu, 28 Jun 2018 14:14:51 +0900 (JST)
>>> Masato Asou  wrote:
>>> > Hi tech,
>>> > 
>>> > I have a problem and I have ad hoc patch to solve this problem.
>>> > However, this patch is AD HOC. Does anybody have correct solution?
>>> > 
>>> > The next command of GDB does not work properly.
>>> > I use OpenBSD 6.3 and /usr/bin/gdb (GDB 6.3).
>>> > 
>>> > When I debuging my program with next command, I expect stop at next
>>> > line. However, program returned from current function unusual. 
>>> > 
>>> > It seems that this problem will occur if there is a WHILE immediately
>>> > after the function call.
>>> > 
>>> > Example as below:
>>> > 
>>> > $ uname -a
>>> > OpenBSD asou-obsd63.soum.co.jp 6.3 GENERIC#100 amd64
>>> > $ cat main.c
>>> > #include 
>>> > #include 
>>> > #include 
>>> > #include 
>>> > 
>>> > int
>>> > main(int argc, char *argv[])
>>> > {
>>> > extern void sub(int);
>>> > int ch;
>>> > int flag_a = 0;
>>> > 
>>> > sub(1);
>>> > while ((ch = getopt(argc, argv, "a")) != -1) {
>>> > switch (ch) {
>>> > case 'a':
>>> > flag_a = 1;
>>> > break;
>>> > default:
>>> > err(1, "Unknown option: %c\n", ch);
>>> > break;
>>> > }
>>> > }
>>> > 
>>> > printf("flag_a = %d\n", flag_a);
>>> > return (0);
>>> > }
>>> > 
>>> > void
>>> > sub(int flag)
>>> > {
>>> > printf("flag = %d\n", flag);
>>> > }
>>> > $ cc -g main.c
>>> > $ gdb a.out
>>> > GNU 

Re: Next command of GDB does not work properly unusual

2018-07-12 Thread YASUOKA Masahiko
On Thu, 12 Jul 2018 10:37:33 +0100
Stuart Henderson  wrote:
> On 2018/07/12 16:16, YASUOKA Masahiko wrote:
>> > The next command of GDB does not work properly.
>> > I use OpenBSD 6.3 and /usr/bin/gdb (GDB 6.3).
>> 
>> It seems that gdb can't read the dwarf generated by clang properly.
>> I found a better fix at the upstream.
>> 
>>
>> https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=ca5f395d6255337974262b4a6f40da531fcf6204
>> 
>> ok?
> 
> I believe that is a post-GPLv3 commit..

Indeed...

>> Index: gnu/usr.bin/binutils/gdb/dwarf2read.c
>> ===
>> RCS file: /var/cvs/openbsd/src/gnu/usr.bin/binutils/gdb/dwarf2read.c,v
>> retrieving revision 1.5
>> diff -u -p -r1.5 dwarf2read.c
>> --- gnu/usr.bin/binutils/gdb/dwarf2read.c27 Dec 2004 21:05:10 -  
>> 1.5
>> +++ gnu/usr.bin/binutils/gdb/dwarf2read.c12 Jul 2018 07:07:57 -
>> @@ -6479,13 +6479,13 @@ dwarf_decode_lines (struct line_header *
>>  * lh->minimum_instruction_length;
>>line += lh->line_base + (adj_opcode % lh->line_range);
>>lh->file_names[file - 1].included_p = 1;
>> -  if (!decode_for_pst_p)
>> +  if (!decode_for_pst_p && is_stmt)
>>  {
>>/* Append row to matrix using current values.  */
>>record_line (current_subfile, line, 
>> check_cu_functions (address, cu));
>>  }
>> -  basic_block = 1;
>> +  basic_block = 0;
>>  }
>>else switch (op_code)
>>  {
>> @@ -6499,7 +6499,7 @@ dwarf_decode_lines (struct line_header *
>>  case DW_LNE_end_sequence:
>>end_sequence = 1;
>>lh->file_names[file - 1].included_p = 1;
>> -  if (!decode_for_pst_p)
>> +  if (!decode_for_pst_p && is_stmt)
>>  record_line (current_subfile, 0, address);
>>break;
>>  case DW_LNE_set_address:
>> 
>> On Thu, 28 Jun 2018 14:14:51 +0900 (JST)
>> Masato Asou  wrote:
>> > Hi tech,
>> > 
>> > I have a problem and I have ad hoc patch to solve this problem.
>> > However, this patch is AD HOC. Does anybody have correct solution?
>> > 
>> > The next command of GDB does not work properly.
>> > I use OpenBSD 6.3 and /usr/bin/gdb (GDB 6.3).
>> > 
>> > When I debuging my program with next command, I expect stop at next
>> > line. However, program returned from current function unusual. 
>> > 
>> > It seems that this problem will occur if there is a WHILE immediately
>> > after the function call.
>> > 
>> > Example as below:
>> > 
>> > $ uname -a
>> > OpenBSD asou-obsd63.soum.co.jp 6.3 GENERIC#100 amd64
>> > $ cat main.c
>> > #include 
>> > #include 
>> > #include 
>> > #include 
>> > 
>> > int
>> > main(int argc, char *argv[])
>> > {
>> > extern void sub(int);
>> > int ch;
>> > int flag_a = 0;
>> > 
>> > sub(1);
>> > while ((ch = getopt(argc, argv, "a")) != -1) {
>> > switch (ch) {
>> > case 'a':
>> > flag_a = 1;
>> > break;
>> > default:
>> > err(1, "Unknown option: %c\n", ch);
>> > break;
>> > }
>> > }
>> > 
>> > printf("flag_a = %d\n", flag_a);
>> > return (0);
>> > }
>> > 
>> > void
>> > sub(int flag)
>> > {
>> > printf("flag = %d\n", flag);
>> > }
>> > $ cc -g main.c
>> > $ gdb a.out
>> > GNU gdb 6.3
>> > Copyright 2004 Free Software Foundation, Inc.
>> > GDB is free software, covered by the GNU General Public License, and you 
>> > are
>> > welcome to change it and/or distribute copies of it under certain 
>> > conditions.
>> > Type "show copying" to see the conditions.
>> > There is absolutely no warranty for GDB.  Type "show warranty" for details.
>> > This GDB was configured as "amd64-unknown-openbsd6.3"...
>> > (gdb) b main
>> > Breakpoint 1 at 0x56b: file main.c, line 11.
>> > (gdb) run
>> > Starting program: /home/asou/tmp/a.out 
>> > Breakpoint 1 at 0x12776150056b: file main.c, line 11.
>> > 
>> > Breakpoint 1, main (argc=1, argv=0x7f7c3b08) at main.c:11
>> > 11  int flag_a = 0;
>> > Current language:  auto; currently minimal
>> > (gdb) next
>> > 13  sub(1);
>> > (gdb) next
>> > flag = 1
>> > 0x127761500579 in main (argc=1, argv=0x7f7c3b08)
>> >from /home/asou/tmp/a.out
>> > (gdb) next
>> > Single stepping until exit from function main, 
>> > which has no line number information.
>> > flag_a = 0
>> > 0x127761500436 in _start () from /home/asou/tmp/a.out
>> > (gdb) bt
>> > #0  0x127761500436 in _start () from /home/asou/tmp/a.out
>> > #1  0x in ?? ()
>> > (gdb) 
>> > 
>> > My patch as below:
>> > 
>> > $ git diff
>> > diff --git a/gnu/usr.bin/binut

Re: Next command of GDB does not work properly unusual

2018-07-12 Thread Stuart Henderson
On 2018/07/12 16:16, YASUOKA Masahiko wrote:
> Hi,
> 
> > The next command of GDB does not work properly.
> > I use OpenBSD 6.3 and /usr/bin/gdb (GDB 6.3).
> 
> It seems that gdb can't read the dwarf generated by clang properly.
> I found a better fix at the upstream.
> 
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=ca5f395d6255337974262b4a6f40da531fcf6204
> 
> ok?

I believe that is a post-GPLv3 commit..

> Index: gnu/usr.bin/binutils/gdb/dwarf2read.c
> ===
> RCS file: /var/cvs/openbsd/src/gnu/usr.bin/binutils/gdb/dwarf2read.c,v
> retrieving revision 1.5
> diff -u -p -r1.5 dwarf2read.c
> --- gnu/usr.bin/binutils/gdb/dwarf2read.c 27 Dec 2004 21:05:10 -  
> 1.5
> +++ gnu/usr.bin/binutils/gdb/dwarf2read.c 12 Jul 2018 07:07:57 -
> @@ -6479,13 +6479,13 @@ dwarf_decode_lines (struct line_header *
>   * lh->minimum_instruction_length;
> line += lh->line_base + (adj_opcode % lh->line_range);
>lh->file_names[file - 1].included_p = 1;
> -  if (!decode_for_pst_p)
> +  if (!decode_for_pst_p && is_stmt)
>  {
> /* Append row to matrix using current values.  */
> record_line (current_subfile, line, 
>  check_cu_functions (address, cu));
>  }
> -   basic_block = 1;
> +   basic_block = 0;
>   }
> else switch (op_code)
>   {
> @@ -6499,7 +6499,7 @@ dwarf_decode_lines (struct line_header *
>   case DW_LNE_end_sequence:
> end_sequence = 1;
>lh->file_names[file - 1].included_p = 1;
> -  if (!decode_for_pst_p)
> +  if (!decode_for_pst_p && is_stmt)
>   record_line (current_subfile, 0, address);
> break;
>   case DW_LNE_set_address:
> 
> On Thu, 28 Jun 2018 14:14:51 +0900 (JST)
> Masato Asou  wrote:
> > Hi tech,
> > 
> > I have a problem and I have ad hoc patch to solve this problem.
> > However, this patch is AD HOC. Does anybody have correct solution?
> > 
> > The next command of GDB does not work properly.
> > I use OpenBSD 6.3 and /usr/bin/gdb (GDB 6.3).
> > 
> > When I debuging my program with next command, I expect stop at next
> > line. However, program returned from current function unusual. 
> > 
> > It seems that this problem will occur if there is a WHILE immediately
> > after the function call.
> > 
> > Example as below:
> > 
> > $ uname -a
> > OpenBSD asou-obsd63.soum.co.jp 6.3 GENERIC#100 amd64
> > $ cat main.c
> > #include 
> > #include 
> > #include 
> > #include 
> > 
> > int
> > main(int argc, char *argv[])
> > {
> > extern void sub(int);
> > int ch;
> > int flag_a = 0;
> > 
> > sub(1);
> > while ((ch = getopt(argc, argv, "a")) != -1) {
> > switch (ch) {
> > case 'a':
> > flag_a = 1;
> > break;
> > default:
> > err(1, "Unknown option: %c\n", ch);
> > break;
> > }
> > }
> > 
> > printf("flag_a = %d\n", flag_a);
> > return (0);
> > }
> > 
> > void
> > sub(int flag)
> > {
> > printf("flag = %d\n", flag);
> > }
> > $ cc -g main.c
> > $ gdb a.out
> > GNU gdb 6.3
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain 
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for details.
> > This GDB was configured as "amd64-unknown-openbsd6.3"...
> > (gdb) b main
> > Breakpoint 1 at 0x56b: file main.c, line 11.
> > (gdb) run
> > Starting program: /home/asou/tmp/a.out 
> > Breakpoint 1 at 0x12776150056b: file main.c, line 11.
> > 
> > Breakpoint 1, main (argc=1, argv=0x7f7c3b08) at main.c:11
> > 11  int flag_a = 0;
> > Current language:  auto; currently minimal
> > (gdb) next
> > 13  sub(1);
> > (gdb) next
> > flag = 1
> > 0x127761500579 in main (argc=1, argv=0x7f7c3b08)
> >from /home/asou/tmp/a.out
> > (gdb) next
> > Single stepping until exit from function main, 
> > which has no line number information.
> > flag_a = 0
> > 0x127761500436 in _start () from /home/asou/tmp/a.out
> > (gdb) bt
> > #0  0x127761500436 in _start () from /home/asou/tmp/a.out
> > #1  0x in ?? ()
> > (gdb) 
> > 
> > My patch as below:
> > 
> > $ git diff
> > diff --git a/gnu/usr.bin/binutils/gdb/dwarf2read.c 
> > b/gnu/usr.bin/binutils/gdb/dwarf2read.c
> > index 96f9e0f8551..651904d763d 100644
> > --- a/gnu/usr.bin/binutils/gdb/dwarf2read.c
> > +++ b/gnu/usr.bin/binutils/gdb/dwa

Re: Next command of GDB does not work properly unusual

2018-07-12 Thread YASUOKA Masahiko
Hi,

> The next command of GDB does not work properly.
> I use OpenBSD 6.3 and /usr/bin/gdb (GDB 6.3).

It seems that gdb can't read the dwarf generated by clang properly.
I found a better fix at the upstream.

   
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=ca5f395d6255337974262b4a6f40da531fcf6204

ok?

Index: gnu/usr.bin/binutils/gdb/dwarf2read.c
===
RCS file: /var/cvs/openbsd/src/gnu/usr.bin/binutils/gdb/dwarf2read.c,v
retrieving revision 1.5
diff -u -p -r1.5 dwarf2read.c
--- gnu/usr.bin/binutils/gdb/dwarf2read.c   27 Dec 2004 21:05:10 -  
1.5
+++ gnu/usr.bin/binutils/gdb/dwarf2read.c   12 Jul 2018 07:07:57 -
@@ -6479,13 +6479,13 @@ dwarf_decode_lines (struct line_header *
* lh->minimum_instruction_length;
  line += lh->line_base + (adj_opcode % lh->line_range);
   lh->file_names[file - 1].included_p = 1;
-  if (!decode_for_pst_p)
+  if (!decode_for_pst_p && is_stmt)
 {
  /* Append row to matrix using current values.  */
  record_line (current_subfile, line, 
   check_cu_functions (address, cu));
 }
- basic_block = 1;
+ basic_block = 0;
}
  else switch (op_code)
{
@@ -6499,7 +6499,7 @@ dwarf_decode_lines (struct line_header *
case DW_LNE_end_sequence:
  end_sequence = 1;
   lh->file_names[file - 1].included_p = 1;
-  if (!decode_for_pst_p)
+  if (!decode_for_pst_p && is_stmt)
record_line (current_subfile, 0, address);
  break;
case DW_LNE_set_address:

On Thu, 28 Jun 2018 14:14:51 +0900 (JST)
Masato Asou  wrote:
> Hi tech,
> 
> I have a problem and I have ad hoc patch to solve this problem.
> However, this patch is AD HOC. Does anybody have correct solution?
> 
> The next command of GDB does not work properly.
> I use OpenBSD 6.3 and /usr/bin/gdb (GDB 6.3).
> 
> When I debuging my program with next command, I expect stop at next
> line. However, program returned from current function unusual. 
> 
> It seems that this problem will occur if there is a WHILE immediately
> after the function call.
> 
> Example as below:
> 
> $ uname -a
> OpenBSD asou-obsd63.soum.co.jp 6.3 GENERIC#100 amd64
> $ cat main.c
> #include 
> #include 
> #include 
> #include 
> 
> int
> main(int argc, char *argv[])
> {
> extern void sub(int);
> int ch;
> int flag_a = 0;
> 
> sub(1);
> while ((ch = getopt(argc, argv, "a")) != -1) {
> switch (ch) {
> case 'a':
> flag_a = 1;
> break;
> default:
> err(1, "Unknown option: %c\n", ch);
> break;
> }
> }
> 
> printf("flag_a = %d\n", flag_a);
> return (0);
> }
> 
> void
> sub(int flag)
> {
> printf("flag = %d\n", flag);
> }
> $ cc -g main.c
> $ gdb a.out
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-unknown-openbsd6.3"...
> (gdb) b main
> Breakpoint 1 at 0x56b: file main.c, line 11.
> (gdb) run
> Starting program: /home/asou/tmp/a.out 
> Breakpoint 1 at 0x12776150056b: file main.c, line 11.
> 
> Breakpoint 1, main (argc=1, argv=0x7f7c3b08) at main.c:11
> 11  int flag_a = 0;
> Current language:  auto; currently minimal
> (gdb) next
> 13  sub(1);
> (gdb) next
> flag = 1
> 0x127761500579 in main (argc=1, argv=0x7f7c3b08)
>from /home/asou/tmp/a.out
> (gdb) next
> Single stepping until exit from function main, 
> which has no line number information.
> flag_a = 0
> 0x127761500436 in _start () from /home/asou/tmp/a.out
> (gdb) bt
> #0  0x127761500436 in _start () from /home/asou/tmp/a.out
> #1  0x in ?? ()
> (gdb) 
> 
> My patch as below:
> 
> $ git diff
> diff --git a/gnu/usr.bin/binutils/gdb/dwarf2read.c 
> b/gnu/usr.bin/binutils/gdb/dwarf2read.c
> index 96f9e0f8551..651904d763d 100644
> --- a/gnu/usr.bin/binutils/gdb/dwarf2read.c
> +++ b/gnu/usr.bin/binutils/gdb/dwarf2read.c
> @@ -6479,7 +6479,11 @@ dwarf_decode_lines (struct line_header *lh, char 
> *comp_dir, bfd *abfd,
> * lh->minimum_instruction_length;
>   line += lh->line_base + (adj_opcode % lh->line_range);
>lh->file_names[file - 1].included_p = 1;
> +#if 0 /* for debug by asou */
>i

Next command of GDB does not work properly unusual

2018-06-27 Thread Masato Asou
Hi tech,

I have a problem and I have ad hoc patch to solve this problem.
However, this patch is AD HOC. Does anybody have correct solution?

The next command of GDB does not work properly.
I use OpenBSD 6.3 and /usr/bin/gdb (GDB 6.3).

When I debuging my program with next command, I expect stop at next
line. However, program returned from current function unusual. 

It seems that this problem will occur if there is a WHILE immediately
after the function call.

Example as below:

$ uname -a
OpenBSD asou-obsd63.soum.co.jp 6.3 GENERIC#100 amd64
$ cat main.c
#include 
#include 
#include 
#include 

int
main(int argc, char *argv[])
{
extern void sub(int);
int ch;
int flag_a = 0;

sub(1);
while ((ch = getopt(argc, argv, "a")) != -1) {
switch (ch) {
case 'a':
flag_a = 1;
break;
default:
err(1, "Unknown option: %c\n", ch);
break;
}
}

printf("flag_a = %d\n", flag_a);
return (0);
}

void
sub(int flag)
{
printf("flag = %d\n", flag);
}
$ cc -g main.c
$ gdb a.out
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.3"...
(gdb) b main
Breakpoint 1 at 0x56b: file main.c, line 11.
(gdb) run
Starting program: /home/asou/tmp/a.out 
Breakpoint 1 at 0x12776150056b: file main.c, line 11.

Breakpoint 1, main (argc=1, argv=0x7f7c3b08) at main.c:11
11  int flag_a = 0;
Current language:  auto; currently minimal
(gdb) next
13  sub(1);
(gdb) next
flag = 1
0x127761500579 in main (argc=1, argv=0x7f7c3b08)
   from /home/asou/tmp/a.out
(gdb) next
Single stepping until exit from function main, 
which has no line number information.
flag_a = 0
0x127761500436 in _start () from /home/asou/tmp/a.out
(gdb) bt
#0  0x127761500436 in _start () from /home/asou/tmp/a.out
#1  0x in ?? ()
(gdb) 

My patch as below:

$ git diff
diff --git a/gnu/usr.bin/binutils/gdb/dwarf2read.c 
b/gnu/usr.bin/binutils/gdb/dwarf2read.c
index 96f9e0f8551..651904d763d 100644
--- a/gnu/usr.bin/binutils/gdb/dwarf2read.c
+++ b/gnu/usr.bin/binutils/gdb/dwarf2read.c
@@ -6479,7 +6479,11 @@ dwarf_decode_lines (struct line_header *lh, char 
*comp_dir, bfd *abfd,
* lh->minimum_instruction_length;
  line += lh->line_base + (adj_opcode % lh->line_range);
   lh->file_names[file - 1].included_p = 1;
+#if 0 /* for debug by asou */
   if (!decode_for_pst_p)
+#else /* for debug by asou */
+  if (line != 0 && !decode_for_pst_p)
+#endif /* for debug by asou */
 {
  /* Append row to matrix using current values.  */
  record_line (current_subfile, line, 
--
ASOU Masato