From: Nicholas Nethercote Date: Tue, 7 May 2002 10:26:57 +0000 (+0000) Subject: vg_symtab2.c: X-Git-Tag: svn/VALGRIND_1_0_3~238 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=53d40a27daf678d1d5571a22d452150c9a2861e4;p=thirdparty%2Fvalgrind.git vg_symtab2.c: - No longer aborting when encountering a N_SOL symbol after the 65535th line in a file, just printing a warning/apology that annotations/messages might be wrong. This is a pain to fix properly, since it requires first guessing when a line number overflow happens, then switching to one or more other files, then switching back. manual: wibble git-svn-id: svn://svn.valgrind.org/valgrind/trunk@225 --- diff --git a/cachegrind/docs/manual.html b/cachegrind/docs/manual.html index 4b6b773915..d4fd738f65 100644 --- a/cachegrind/docs/manual.html +++ b/cachegrind/docs/manual.html @@ -2508,8 +2508,7 @@ Some odd things that can occur during annotation: mov %esi,%esi to it.

-

  • - Inlined functions can cause strange results in the function-by-function +
  • Inlined functions can cause strange results in the function-by-function summary. If a function inline_me() is defined in foo.h and inlined in the functions f1(), f2() and f3() in bar.c, there will @@ -2524,13 +2523,21 @@ Some odd things that can occur during annotation: doesn't indicate the name of the function in foo.h, so Valgrind keeps using the old one.

    -

  • - Sometimes, the same filename might be represented with a relative name +
  • Sometimes, the same filename might be represented with a relative name and with an absolute name in different parts of the debug info, eg: /home/user/proj/proj.h and ../proj.h. In this case, if you use auto-annotation, the file will be annotated twice with the counts split between the two.

    • + +
  • Files with more than 65,535 lines cause difficulties for the stabs debug + info reader. This is because the line number in the struct + nlist defined in a.out.h under Linux is only a 16-bit + number. Valgrind can handle some files with more than 65,535 lines + correctly by making some guesses to identify line number overflows. But + some cases are beyond it, in which case you'll get a warning message + explaining that annotations for the file might be incorrect. +
    • Note: stabs is not an easy format to read. If you come across bizarre @@ -2584,7 +2591,6 @@ hopefully they should be close enough to be useful.

    interesting and just complicate the output. Would be nice to exclude these somehow.

    -

  • Handle files with more than 65535 lines.

    • diff --git a/coregrind/docs/manual.html b/coregrind/docs/manual.html index 4b6b773915..d4fd738f65 100644 --- a/coregrind/docs/manual.html +++ b/coregrind/docs/manual.html @@ -2508,8 +2508,7 @@ Some odd things that can occur during annotation: mov %esi,%esi to it.

    -

  • - Inlined functions can cause strange results in the function-by-function +
  • Inlined functions can cause strange results in the function-by-function summary. If a function inline_me() is defined in foo.h and inlined in the functions f1(), f2() and f3() in bar.c, there will @@ -2524,13 +2523,21 @@ Some odd things that can occur during annotation: doesn't indicate the name of the function in foo.h, so Valgrind keeps using the old one.

    -

  • - Sometimes, the same filename might be represented with a relative name +
  • Sometimes, the same filename might be represented with a relative name and with an absolute name in different parts of the debug info, eg: /home/user/proj/proj.h and ../proj.h. In this case, if you use auto-annotation, the file will be annotated twice with the counts split between the two.

    • + +
  • Files with more than 65,535 lines cause difficulties for the stabs debug + info reader. This is because the line number in the struct + nlist defined in a.out.h under Linux is only a 16-bit + number. Valgrind can handle some files with more than 65,535 lines + correctly by making some guesses to identify line number overflows. But + some cases are beyond it, in which case you'll get a warning message + explaining that annotations for the file might be incorrect. +
    • Note: stabs is not an easy format to read. If you come across bizarre @@ -2584,7 +2591,6 @@ hopefully they should be close enough to be useful.

    interesting and just complicate the output. Would be nice to exclude these somehow.

    -

  • Handle files with more than 65535 lines.

    • diff --git a/coregrind/vg_symtab2.c b/coregrind/vg_symtab2.c index c269b77bd5..cc37053862 100644 --- a/coregrind/vg_symtab2.c +++ b/coregrind/vg_symtab2.c @@ -1067,8 +1067,11 @@ void vg_read_lib_symbols ( SegInfo* si ) case N_SOL: if (lineno_overflows != 0) { - VG_(panic)("Can't currently handle include files in very long " - "(> 65535 lines) files. Sorry."); + VG_(message)(Vg_UserMsg, + "Warning: file %s is very big (> 65535 lines) " + "Line numbers and annotation for this file might " + "be wrong. Sorry", + curr_file_name); } /* fall through! */ case N_SO: diff --git a/docs/manual.html b/docs/manual.html index 4b6b773915..d4fd738f65 100644 --- a/docs/manual.html +++ b/docs/manual.html @@ -2508,8 +2508,7 @@ Some odd things that can occur during annotation: mov %esi,%esi to it.

    -

  • - Inlined functions can cause strange results in the function-by-function +
  • Inlined functions can cause strange results in the function-by-function summary. If a function inline_me() is defined in foo.h and inlined in the functions f1(), f2() and f3() in bar.c, there will @@ -2524,13 +2523,21 @@ Some odd things that can occur during annotation: doesn't indicate the name of the function in foo.h, so Valgrind keeps using the old one.

    -

  • - Sometimes, the same filename might be represented with a relative name +
  • Sometimes, the same filename might be represented with a relative name and with an absolute name in different parts of the debug info, eg: /home/user/proj/proj.h and ../proj.h. In this case, if you use auto-annotation, the file will be annotated twice with the counts split between the two.

    • + +
  • Files with more than 65,535 lines cause difficulties for the stabs debug + info reader. This is because the line number in the struct + nlist defined in a.out.h under Linux is only a 16-bit + number. Valgrind can handle some files with more than 65,535 lines + correctly by making some guesses to identify line number overflows. But + some cases are beyond it, in which case you'll get a warning message + explaining that annotations for the file might be incorrect. +
    • Note: stabs is not an easy format to read. If you come across bizarre @@ -2584,7 +2591,6 @@ hopefully they should be close enough to be useful.

    interesting and just complicate the output. Would be nice to exclude these somehow.

    -

  • Handle files with more than 65535 lines.

    • diff --git a/memcheck/docs/manual.html b/memcheck/docs/manual.html index 4b6b773915..d4fd738f65 100644 --- a/memcheck/docs/manual.html +++ b/memcheck/docs/manual.html @@ -2508,8 +2508,7 @@ Some odd things that can occur during annotation: mov %esi,%esi to it.

    -

  • - Inlined functions can cause strange results in the function-by-function +
  • Inlined functions can cause strange results in the function-by-function summary. If a function inline_me() is defined in foo.h and inlined in the functions f1(), f2() and f3() in bar.c, there will @@ -2524,13 +2523,21 @@ Some odd things that can occur during annotation: doesn't indicate the name of the function in foo.h, so Valgrind keeps using the old one.

    -

  • - Sometimes, the same filename might be represented with a relative name +
  • Sometimes, the same filename might be represented with a relative name and with an absolute name in different parts of the debug info, eg: /home/user/proj/proj.h and ../proj.h. In this case, if you use auto-annotation, the file will be annotated twice with the counts split between the two.

    • + +
  • Files with more than 65,535 lines cause difficulties for the stabs debug + info reader. This is because the line number in the struct + nlist defined in a.out.h under Linux is only a 16-bit + number. Valgrind can handle some files with more than 65,535 lines + correctly by making some guesses to identify line number overflows. But + some cases are beyond it, in which case you'll get a warning message + explaining that annotations for the file might be incorrect. +
    • Note: stabs is not an easy format to read. If you come across bizarre @@ -2584,7 +2591,6 @@ hopefully they should be close enough to be useful.

    interesting and just complicate the output. Would be nice to exclude these somehow.

    -

  • Handle files with more than 65535 lines.

    • diff --git a/vg_symtab2.c b/vg_symtab2.c index c269b77bd5..cc37053862 100644 --- a/vg_symtab2.c +++ b/vg_symtab2.c @@ -1067,8 +1067,11 @@ void vg_read_lib_symbols ( SegInfo* si ) case N_SOL: if (lineno_overflows != 0) { - VG_(panic)("Can't currently handle include files in very long " - "(> 65535 lines) files. Sorry."); + VG_(message)(Vg_UserMsg, + "Warning: file %s is very big (> 65535 lines) " + "Line numbers and annotation for this file might " + "be wrong. Sorry", + curr_file_name); } /* fall through! */ case N_SO: