Hi all,
I’ve been looking at the linenumbers element in struct program as a means of getting offsets for a given line number. Since a program can be made up of multiple files through includes, I need to make sure that when I look through the entries, that I’m only comparing line numbers that come from the file I’m interested in. The initial file marker entry appears correctly, however, when the file changes, a new marker entry doesn’t seem to be inserted in the array. I see that the line numbers jump correctly, but there is no other indication that the source of the lines has changed.
Is this intentional, or am I missing something?
Here’s an example tracing through a program with a file included within a function definition.
cnt: 127 <— beginning of program new file file: /Users/hww3/bpt.pike cnt: 0 line: 0 0x0 cnt: 36 line: 2 0x24 cnt: -127 line: 4 0xcd cnt: 54 line: 5 0x103 cnt: -127 line: 8 0x1ab cnt: -127 line: 9 0x23e cnt: 34 line: 10 0x260 cnt: 116 line: 12 0x2d4 cnt: -127 line: 14 0x37d cnt: 69 line: 15 0x3c2 cnt: -127 line: 16 0x467 cnt: -127 line: 18 0x52c cnt: -127 line: 19 0x5ff cnt: 76 line: 1 0x64b <— included file, line number jumps to 1, but no marker cnt: 114 line: 2 0x6bd cnt: 80 line: 21 0x70d <— back to original file, but also no marker cnt: -127 line: 22 0x7a6
Hi all,
Hi Bill.
Iâve been looking at the linenumbers element in struct program as a means of getting offsets for a given line number. Since a program can be made up of multiple files through includes, I need to make sure that when I look through the entries, that Iâm only comparing line numbers that come from the file Iâm interested in. The initial file marker entry appears correctly, however, when the file changes, a new marker entry doesnât seem to be inserted in the array. I see that the line numbers jump correctly, but there is no other indication that the source of the lines has changed.
Is this intentional, or am I missing something?
Hereâs an example tracing through a program with a file included within a function definition.
[...]
Hard to say; can you provide a hex dump of the line number table?
A trivial test case gives that #line directives seem to work in both Pike 8.0 and 8.1:
| Pike v8.0 release 702 running Hilfe v3.5 (Incremental Pike Frontend) | > program p = compile_string("#line 17 "foo"\nint foo(){\n error("Bang!\n");\n}\n", "bar"); | > object o = p(); | > o->foo(); | Bang! | foo:18: bar()->foo()
| Pike v8.1 release 13 running Hilfe v3.5 (Incremental Pike Frontend) | > program p = compile_string("#line 17 "foo"\nint foo(){\n error("Bang!\n");\n}\n", "bar"); | > object o = p(); | > o->foo(); | Bang! | foo:18: bar()->foo()
What version of Pike are you using?
Is the output from the cpp()-pass correct? Maybe I broke cpp() during the Pike 8.1 cpp-rewrite.
/grubba
Hi Grubba…
I’m using 8.1 freshly compiled from master. The results of cpp() look good, but when I throw an error the file name is incorrect (it shows the line number of the included file, but the filename of the file that contains the #include directive.)
Example (note the file inclusion within whee()):
Pike v8.1 release 13 running Hilfe v3.5 (Incremental Pike Frontend)
cpp(Stdio.read_file("./bpt.pike"), "./bpt.pike");
(1) Result: "#line 1 "./bpt.pike"\n" "object debugger;\n" "int main () {\n" " \n" " program p = this_program;\n" " add_breakpoint(p, 22);\n" "\n" " \n" " call_out(doit, 5);\n" " return -1;\n" "}\n" "\n" "void doit() {\n" " \n" " mixed res = whee("rad");\n" " werror("***\n*** result: %O\n***\n", res);\n" "}\n" "\n" "int whee(string w) {\n" " werror("foo\n");\n" "#line 1 "/Users/hww3/bpt.h"\n" "int x = 0;\n" "error("gee!\n");\n" "\n" "#line 20 "./bpt.pike"\n" "\n" " string q = "wq";\n" " q+="21";\n" " q+="22";\n" "werror("bar " + w + "\n");\n" " return 27;\n" "}\n"
compile_file("./bpt.pike");
(2) Result: bpt.pike
compile_file("./bpt.pike")()->whee("");
foo gee! ./bpt.pike:2: bpt.pike()->whee(“")
Here’s what line numbers look like:
(lldb) p prog->num_linenumbers (size_t) $0 = 66 (lldb) parray/x 66 prog->linenumbers (char *) $1 = 0x0000000101e351d0 "\x7f" { (char) [0] = 0x7f (char) [1] = 0x00 (char) [2] = 0x00 (char) [3] = 0x00 (char) [4] = 0x24 (char) [5] = 0x02 (char) [6] = 0x81 (char) [7] = 0x00 (char) [8] = 0xa9 (char) [9] = 0x02 (char) [10] = 0x36 (char) [11] = 0x01 (char) [12] = 0x81 (char) [13] = 0x00 (char) [14] = 0xa8 (char) [15] = 0x03 (char) [16] = 0x81 (char) [17] = 0x00 (char) [18] = 0x93 (char) [19] = 0x01 (char) [20] = 0x22 (char) [21] = 0x01 (char) [22] = 0x74 (char) [23] = 0x02 (char) [24] = 0x81 (char) [25] = 0x00 (char) [26] = 0xa9 (char) [27] = 0x02 (char) [28] = 0x45 (char) [29] = 0x01 (char) [30] = 0x81 (char) [31] = 0x00 (char) [32] = 0xa5 (char) [33] = 0x01 (char) [34] = 0x81 (char) [35] = 0x00 (char) [36] = 0xc5 (char) [37] = 0x02 (char) [38] = 0x81 (char) [39] = 0x00 (char) [40] = 0xd3 (char) [41] = 0x01 (char) [42] = 0x4c (char) [43] = 0xee (char) [44] = 0x72 (char) [45] = 0x01 (char) [46] = 0x50 (char) [47] = 0x13 (char) [48] = 0x81 (char) [49] = 0x00 (char) [50] = 0x99 (char) [51] = 0x01 (char) [52] = 0x81 (char) [53] = 0x00 (char) [54] = 0x88 (char) [55] = 0x01 (char) [56] = 0x81 (char) [57] = 0x00 (char) [58] = 0x8f (char) [59] = 0x01 (char) [60] = 0x81 (char) [61] = 0x00 (char) [62] = 0xab (char) [63] = 0x01 (char) [64] = 0x29 (char) [65] = 0x01 }
Hi Grubbaâ¦
Iâm using 8.1 freshly compiled from master. The results of cpp() look good, but when I throw an error the file name is incorrect (it shows the line number of the included file, but the filename of the file that contains the #include directive.)
Example (note the file inclusion within whee()):
[...]
Thanks! That code triggered two different bugs that both caused the bpt.h filename to get lost in backtraces.
Fixed in Pike 8.0 and master.
/grubba
Thanks, Grubba… my backtraces look good now!
Bill
On Nov 21, 2018, at 7:14 AM, Henrik Grubbström (Lysator) @ Pike (-) developers forum 10353@lyskom.lysator.liu.se wrote:
Hi Grubbaâ¦
Iâm using 8.1 freshly compiled from master. The results of cpp() look good, but when I throw an error the file name is incorrect (it shows the line number of the included file, but the filename of the file that contains the #include directive.)
Example (note the file inclusion within whee()):
[...]
Thanks! That code triggered two different bugs that both caused the bpt.h filename to get lost in backtraces.
Fixed in Pike 8.0 and master.
/grubba
Great. Maybe you could also fix the testcase you committed into 8.0 so that it actually compiles? ;-) (8.0 requires a ; after nested function definitions.)
The following commit
--8<-- commit 9d3049763c370622ee1159129ddca919986684b5 Author: Mateusz Krawczuk 209147@student.pwr.edu.pl Date: Sun Nov 4 16:37:24 2018 +0100
if -> else if
--8<--
changed the character encoding of master.pike.in from ISO-8859-1 to UTF-8. (Maybe the commit message should have mentioned this?) Because Pike itself was not informed of this change, the output from "pike --version" is now
--8<-- Pike v8.1 release 13 Copyright © 1994-2018 Linköping University --8<--
in an UTF-8 locale, and
--8<-- Pike v8.1 release 13 Copyright Ã\202© 1994-2018 LinkÃ\203¶ping University --8<--
in an ISO-8859-1 locale, which is not exactly ideal.
A number of questions arise:
1) Is it in fact possible to specify a character encoding other than ISO-8859-1 for master.pike? I suspect not, since #charset is handled by the master...
2) Shouldn't the implementation of --version use the set_charset(0) feature of Stdio.FILE to encode the message with the current locale, instead of blindly assuming an UTF-8 locale (currently there is a hardcoded call to string_to_utf8 here...)? Which I guess means that it's really werror which should do it, so that users of werror/exit don't need to care? (This was actually suggested by Per when he added the string_to_utf8 call in 2009 :)
3) Looking at set_charset(0), isn't it an omission that it doesn't check LC_ALL and LC_CTYPE before LANG?
If nobody protests I'll take a stab at making werror locale sensitive (and updating set_charset(0) to look at LC_ALL and LC_CTYPE).
I think it's fine to have it as ISO-8859-1 as long as it is documented. My pending commit adds a line
//#charset iso-8859-1 // hardcoded, can not be changed
pike-devel@lists.lysator.liu.se