I'm compiling LLVM as well as clang. I noticed that the output of compilation has llvm[1]: or llvm[2]: or llvm[3]: prefixed to each line. What do those integers in brackets mean?
Apparently, it's not connected to the number of the compilation job (can be easily checked via make -j 1). The autoconf-based build system indicates the "level" of the makefile inside the source tree). To be prices, it's a value of make's MAKELEVEL variable.
The currently accepted answer is not correct. Furthermore, this is really a GNU Make question, not a LLVM question.
What you're seeing is the current value of the MAKELEVEL variable echoed by make to the command line. This value is set as a result of recursive execution. From the GNU make manual:
As a special feature, the variable MAKELEVEL is changed when it is passed down from level to level. This variable’s value is a string which is the depth of the level as a decimal number. The value is ‘0’ for the top-level make; ‘1’ for a sub-make, ‘2’ for a sub-sub-make, and so on. The incrementation happens when make sets up the environment for a recipe.
If you have a copy of the GNU Make source code on hand, you can see your output message being generated in output.c with the void message(...) function. In GNU make v4.2, this happens on line 626. Specifically the program argument is set to the string "llvm" and the makelevel argument is set as noted above.
Since it was erroneously brought up, it is not the number of the compilation job. The -j [jobs] or --jobs[=jobs] options enable parallel execution of up to jobs number of recipes simultaneously. If -j or --jobs is selected, but jobs is not set, GNU Make attempts to execute as many recipes simultaneously as possible. See this section of the GNU Make manual for more information.
It is possible to have recursive execution without parallel execution, and parallel execution without recursive execution. This is the main reason that the currently accepted answer is not correct.
It's the number of the compilation job (make -j). Helpful to trace compilation errors.
Related
I've seen many COBOL programs contain sections with at the end
XX-99.
EXIT.
Many times that paragraph is used to exit the section, for instance with GO TO XX-99. I have read that EXIT is a no-operation, as it doesn't do anything. But the same goes for CONTINUE. One could easily replace EXIT with CONTINUE. Alternatively, one could replace GO TO XX-99 with EXIT SECTION.
Is there any compelling reason to use EXIT rather than CONTINUE? Why was EXIT introduced anyway? Was EXIT introduced before CONTINUE was?
Note: I'm not talking about EXIT in combination with another reserved word, like EXIT PROGRAM or EXIT PERFORM.
Is there any compelling reason to use EXIT rather than CONTINUE?
Why was EXIT introduced anyway?
Was EXIT introduced before CONTINUE was?
There is no "compelling" reason to choose one over the other. There is no practical difference. The reason to choose EXIT over CONTINUE is conformance to existing coding standards.
EXIT was part of the original COBOL 60 Report where it was a "Compiler Directing Verb." Its purpose was to mark the end of a performed procedure, directing the compiler to transfer control to the statement following the invoking PERFORM statement or to the PERFORM statement for the next iteration of a loop.
In the ANSI COBOL 68 standard, it became a statement to mark the end of a performed procedure. It was no longer required, since the end of the perform range was the end of the last (or only) performed paragraph or section. It remained as a convenient target for a GO TO statement.
[With the introduction of the SORT statement, an EXIT statement may also be used to mark the end of an input or output procedure.]
CONTINUE was introduced in the 1985 standard as part of the changes for structured programming. It purpose was to replace the NEXT SENTENCE statement used within the IF and SEARCH statements or wherever an imperative statement is required by a statement format, but nothing need be done. It is in this last use that a CONTINUE statement may be used to replace an EXIT statement.
EXIT SECTION was introduced in the 2002 standard.
The 2014 standard still says:
The EXIT statement provides a common end point for a series of procedures [...]
[it] shall appear in a sentence by itself that shall be the only sentence in the paragraph [...]
[and] serves only to enable the user to assign a procedure-name to a given point in a procedure division.
Such an EXIT statement has no other effect on the compilation or execution.
Even in COBOL 202x this format it still is not marked archaic (while the EXIT PROGRAM format is, because of the same functionality provided by GOBACK).
With its different syntax rules to the CONTINUE statement it is already not the same (though some COBOL compilers don't enforce this rule and some of those also don't have an option to even create a warning if this rule is broken).
Concerning the originating: COBOL-74 does not seem to have a CONTINUE statement (at least my copy of VAX-11 COBOL-74 does not list it), it seems to have come in together with the inline format of the PERFORM statement in COBOL-85.
I personally would also prefer the procedure format of EXIT (EXIT SECTION or even EXIT PARAGRAPH if no sections are used in the program) over a GO TO, but as always with COBOL: follow whatever your team-/house-rules are, some may also forbid those.
In my objdump -t output, I see the following two lines:
00000000000004d2 l F .text.unlikely 00000000000000ec function-signature-goes-here [clone .cold.427]
and
00000000000018e0 g F .text 0000000000000690 function-signature-goes-here
I know l means local and g means global. I also know that .text is a section, or a type of section, in an object file, containing compiled program instructions. But what is .text.unlikely? Assuming it's a different section (or type-of-section) from .text - what's the difference?
In my GCC v5.4.0 manpage, I found the following switch:
-freorder-functions
which says:
Reorder functions in the object file in order to improve code
locality. This is implemented by using special subsections
".text.hot" for most frequently executed functions and
".text.unlikely" for unlikely executed functions. Reordering is done
by the linker so object file format must support named sections and
linker must place them in a reasonable way.
Also profile feedback must be available to make this option effective.
See -fprofile-arcs for details.
Enabled at levels -O2, -O3, -Os.
Looks like the compiler was run with optimization flags or that switch for this binary, and functions are organized in subsections to optimize spatial locality.
I'm just starting out with Coveralls and testing coverage and I see info such as this. What do the arrays mean? How should I interpret these? I can't seem to find anywhere in the docs or online regarding the meaning of these.
First index is block number and the second is branch number assigned by GCC
Basing my theory on lcov documentation for branch coverage information
BRDA: line number,block number,branch number,taken
Block number and branch number are gcc internal IDs for the branch.
Taken is either '-' if the basic block containing the branch was never
executed or a number indicating how often that branch was taken.
I wrote the following code in the file "orgin.lua"
if test==nil then
print(aa["bb"]["cc"]) -- to produce a crash
end
print(1120)
when it crash ,it will generate the following information:
lua: origin.lua:3: attempt to index global 'aa' (a nil value)
In order to prevent decompilation and make sure the code is safe,I use the following command to convert my code:
luac -o -s test.lua origin.lua
I know the argument -s is strip debug information, then it do not show the number of rows when crash:
lua: ?:0: attempt to index global 'aa' (a nil value)
but how to bring debugging information when encryption then lua code use luac?Is there any solution?
There is no way to do this built into Lua, but there are some work-arounds.
If you only need line numbers, then one option is to leave the line numbers in the chunk. Line numbers are not that useful for reverse engineering (unluac currently doesn't use them at all), so it shouldn't affect security. Lua doesn't provide an option for this, but it is easy to modify Lua to leave them in when stripping. From ldump.c
n = (D->strip) ? 0 : f->sizelineinfo;
can be changed to
n = f->sizelineinfo;
(Disclaimer: untested)
A more complicated option would be to modify the Lua runtime to output the virtual machine program counter instead of the line number, and also output information describing the location of the current function in the chunk (e.g. top level, first function, second function nested in third function, etc). Then the line number could be looked up by the developer in a non-stripped version of the chunk. (Here is a reference to someone using this approach on lua-l -- no source code was provided, though.)
Note that preventing decompilation is not true security. It may help against casual attacks, but Lua bytecode is not hard to read.
luac does not encrypt the output. It compiles your Lua source code to bytecode, that's all. The code is neither encrypted nor does it run any faster, only the loadtime is shorter since the compilation step is not needed.
If you want your code to be encrypted, I suggest to encrypt the bytecode using e.g. AES-256 and then decode it in memory just before handing it to the Lua state. This way the bytecode is encrypted on disk, but decripted in memory.
The overhead is low. We use this technique since years.
I'm creating a command line parser and want to support option bundling. However, I'm not sure how to handle ambiguities and conflicts that can arise. Consider the three following cases:
1.
-I accepts a string
"-Iinclude" -> Would be parsed as "-I include"
2.
-I accepts a string
-n accepts an integer
"-Iincluden10" -> Would be parsed as "-I include -n 10" because the 'cluden10' after the first occurrence of 'n' cannot be parsed as an integer.
3.
-I accepts a string
-n accepts an integer
-c accepts a string
"-Iin10clude" -> ??? What now ???
How do I handle the last string? There are multiple ways of parsing it, so do I just throw an error informing the user about the ambiguity or do I choose to parse the string that yields the most, i.e. as "-I i -n 10 -c lude"?
I could not find any detailed conventions online, but personally, I'd flag this as an ambiguity error.
As far as I know, there is no standard on command-line parameter parsing, nor even a cross-platform consensus. So the best we can do is appeal to common-sense and the principle of least astonishment.
The Posix standard suggests some guidelines for parsing command-line parameters. They are just guidelines; as the linked section indicates, some standard shell utilities don't conform. And all while Gnu utilities are expected to conform to the Posix guidelines, they also typically deviate in some respects, including the use of "long" parameters.
In any event, what Posix says about grouping is:
One or more options without option-arguments, followed by at most one option that takes an option-argument, should be accepted when grouped behind one '-' delimiter.
Note that Posix options are all single character options. Note also that the guideline is clear that only the last option in an option group is permitted to be an option which might accept an argument.
With respect to Gnu-style long options, I don't know of a standard other than the behaviour of the getopt_long utility. This utility implements Posix style for single character options, including the above-mentioned grouped option syntax; it allows single character options which take arguments to either be immediately followed by the argument, or to be at the end of an (possibly singular) options group with the argument as the following word.
For long options, grouping is not allowed, regardless of whether the option accepts arguments. If the option does accept arguments, two styles are allowed: either the option is immediately followed by an = and then the argument, or the argument is the following word.
In Gnu style, long options cannot be confused with single-character options, because the long options must be specified with two dashes (--).
By contrast, many TCL/Tk-based utilities (and some other command-line parsers) allow long options with a single -, but do not allow option grouping.
In all of these styles, options are divided into two disjoint sets: those that take arguments, and those that do not.
None of these systems are ambiguous, although a random mix of styles, as you seem to be proposing, would be. Even with formal disambiguation rules, ambiguity is dangerous, particularly in console applications where a command line can be irreversible. Furthermore, contextual disambiguation can (even silently) change meaning if the set of available options is extended in the future, which would be a source of hard-to-predict errors in scripts.
Consequently, I'd recommend sticking to a simple existing practice such as Gnu, and to not try too hard to interpret incorrect command lines which do not conform.