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 a5019735-40e9-0310-863c-91ae7b9d1cf9
diff --git a/cachegrind/docs/manual.html b/cachegrind/docs/manual.html
index 4b6b773..d4fd738 100644
--- a/cachegrind/docs/manual.html
+++ b/cachegrind/docs/manual.html
@@ -2508,8 +2508,7 @@
<code>mov %esi,%esi</code> to it.<p>
</li>
- <li>
- Inlined functions can cause strange results in the function-by-function
+ <li>Inlined functions can cause strange results in the function-by-function
summary. If a function <code>inline_me()</code> is defined in
<code>foo.h</code> and inlined in the functions <code>f1()</code>,
<code>f2()</code> and <code>f3()</code> in <code>bar.c</code>, there will
@@ -2524,13 +2523,21 @@
doesn't indicate the name of the function in <code>foo.h</code>, so
Valgrind keeps using the old one.<p>
- <li>
- Sometimes, the same filename might be represented with a relative name
+ <li>Sometimes, the same filename might be represented with a relative name
and with an absolute name in different parts of the debug info, eg:
<code>/home/user/proj/proj.h</code> and <code>../proj.h</code>. In this
case, if you use auto-annotation, the file will be annotated twice with
the counts split between the two.<p>
</li>
+
+ <li>Files with more than 65,535 lines cause difficulties for the stabs debug
+ info reader. This is because the line number in the <code>struct
+ nlist</code> defined in <code>a.out.h</code> 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.
+ </li>
</ul>
Note: stabs is not an easy format to read. If you come across bizarre
@@ -2584,7 +2591,6 @@
interesting and just complicate the output. Would be nice to exclude
these somehow.</li>
<p>
- <li>Handle files with more than 65535 lines.</li><p>
</ul>
<hr width="100%">
</body>
diff --git a/coregrind/docs/manual.html b/coregrind/docs/manual.html
index 4b6b773..d4fd738 100644
--- a/coregrind/docs/manual.html
+++ b/coregrind/docs/manual.html
@@ -2508,8 +2508,7 @@
<code>mov %esi,%esi</code> to it.<p>
</li>
- <li>
- Inlined functions can cause strange results in the function-by-function
+ <li>Inlined functions can cause strange results in the function-by-function
summary. If a function <code>inline_me()</code> is defined in
<code>foo.h</code> and inlined in the functions <code>f1()</code>,
<code>f2()</code> and <code>f3()</code> in <code>bar.c</code>, there will
@@ -2524,13 +2523,21 @@
doesn't indicate the name of the function in <code>foo.h</code>, so
Valgrind keeps using the old one.<p>
- <li>
- Sometimes, the same filename might be represented with a relative name
+ <li>Sometimes, the same filename might be represented with a relative name
and with an absolute name in different parts of the debug info, eg:
<code>/home/user/proj/proj.h</code> and <code>../proj.h</code>. In this
case, if you use auto-annotation, the file will be annotated twice with
the counts split between the two.<p>
</li>
+
+ <li>Files with more than 65,535 lines cause difficulties for the stabs debug
+ info reader. This is because the line number in the <code>struct
+ nlist</code> defined in <code>a.out.h</code> 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.
+ </li>
</ul>
Note: stabs is not an easy format to read. If you come across bizarre
@@ -2584,7 +2591,6 @@
interesting and just complicate the output. Would be nice to exclude
these somehow.</li>
<p>
- <li>Handle files with more than 65535 lines.</li><p>
</ul>
<hr width="100%">
</body>
diff --git a/coregrind/vg_symtab2.c b/coregrind/vg_symtab2.c
index c269b77..cc37053 100644
--- a/coregrind/vg_symtab2.c
+++ b/coregrind/vg_symtab2.c
@@ -1067,8 +1067,11 @@
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 4b6b773..d4fd738 100644
--- a/docs/manual.html
+++ b/docs/manual.html
@@ -2508,8 +2508,7 @@
<code>mov %esi,%esi</code> to it.<p>
</li>
- <li>
- Inlined functions can cause strange results in the function-by-function
+ <li>Inlined functions can cause strange results in the function-by-function
summary. If a function <code>inline_me()</code> is defined in
<code>foo.h</code> and inlined in the functions <code>f1()</code>,
<code>f2()</code> and <code>f3()</code> in <code>bar.c</code>, there will
@@ -2524,13 +2523,21 @@
doesn't indicate the name of the function in <code>foo.h</code>, so
Valgrind keeps using the old one.<p>
- <li>
- Sometimes, the same filename might be represented with a relative name
+ <li>Sometimes, the same filename might be represented with a relative name
and with an absolute name in different parts of the debug info, eg:
<code>/home/user/proj/proj.h</code> and <code>../proj.h</code>. In this
case, if you use auto-annotation, the file will be annotated twice with
the counts split between the two.<p>
</li>
+
+ <li>Files with more than 65,535 lines cause difficulties for the stabs debug
+ info reader. This is because the line number in the <code>struct
+ nlist</code> defined in <code>a.out.h</code> 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.
+ </li>
</ul>
Note: stabs is not an easy format to read. If you come across bizarre
@@ -2584,7 +2591,6 @@
interesting and just complicate the output. Would be nice to exclude
these somehow.</li>
<p>
- <li>Handle files with more than 65535 lines.</li><p>
</ul>
<hr width="100%">
</body>
diff --git a/memcheck/docs/manual.html b/memcheck/docs/manual.html
index 4b6b773..d4fd738 100644
--- a/memcheck/docs/manual.html
+++ b/memcheck/docs/manual.html
@@ -2508,8 +2508,7 @@
<code>mov %esi,%esi</code> to it.<p>
</li>
- <li>
- Inlined functions can cause strange results in the function-by-function
+ <li>Inlined functions can cause strange results in the function-by-function
summary. If a function <code>inline_me()</code> is defined in
<code>foo.h</code> and inlined in the functions <code>f1()</code>,
<code>f2()</code> and <code>f3()</code> in <code>bar.c</code>, there will
@@ -2524,13 +2523,21 @@
doesn't indicate the name of the function in <code>foo.h</code>, so
Valgrind keeps using the old one.<p>
- <li>
- Sometimes, the same filename might be represented with a relative name
+ <li>Sometimes, the same filename might be represented with a relative name
and with an absolute name in different parts of the debug info, eg:
<code>/home/user/proj/proj.h</code> and <code>../proj.h</code>. In this
case, if you use auto-annotation, the file will be annotated twice with
the counts split between the two.<p>
</li>
+
+ <li>Files with more than 65,535 lines cause difficulties for the stabs debug
+ info reader. This is because the line number in the <code>struct
+ nlist</code> defined in <code>a.out.h</code> 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.
+ </li>
</ul>
Note: stabs is not an easy format to read. If you come across bizarre
@@ -2584,7 +2591,6 @@
interesting and just complicate the output. Would be nice to exclude
these somehow.</li>
<p>
- <li>Handle files with more than 65535 lines.</li><p>
</ul>
<hr width="100%">
</body>
diff --git a/vg_symtab2.c b/vg_symtab2.c
index c269b77..cc37053 100644
--- a/vg_symtab2.c
+++ b/vg_symtab2.c
@@ -1067,8 +1067,11 @@
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: