There are a bunch of environment variables that control dyld launch, several of them very useful for debugging performance problems. Not all of them are documented.
These ones are explained in the dyld man page (at least on macOS 10.13)
DYLD_FRAMEWORK_PATH
DYLD_FALLBACK_FRAMEWORK_PATH
DYLD_VERSIONED_FRAMEWORK_PATH
DYLD_LIBRARY_PATH
DYLD_FALLBACK_LIBRARY_PATH
DYLD_VERSIONED_LIBRARY_PATH
DYLD_PRINT_TO_FILE
DYLD_SHARED_REGION
DYLD_INSERT_LIBRARIES
DYLD_FORCE_FLAT_NAMESPACE
DYLD_IMAGE_SUFFIX
DYLD_PRINT_OPTS
DYLD_PRINT_ENV
DYLD_PRINT_LIBRARIES
DYLD_BIND_AT_LAUNCH
DYLD_DISABLE_DOFS
DYLD_PRINT_APIS
DYLD_PRINT_BINDINGS
DYLD_PRINT_INITIALIZERS
DYLD_PRINT_REBASINGS
DYLD_PRINT_SEGMENTS
DYLD_PRINT_STATISTICS
DYLD_PRINT_DOFS
DYLD_PRINT_RPATHS
DYLD_SHARED_CACHE_DIR
DYLD_SHARED_CACHE_DONT_VALIDATE
This one is documented in man dyld, but isn't listed in the list at the top:
DYLD_PRINT_STATISTICS_DETAILS
These are undocumented:
DYLD_ROOT_PATH
DYLD_PATHS_ROOT
DYLD_DISABLE_PREFETCH
DYLD_PRINT_LIBRARIES_POST_LAUNCH
DYLD_NEW_LOCAL_SHARED_REGIONS
DYLD_NO_FIX_PREBINDING
DYLD_PREBIND_DEBUG
DYLD_PRINT_TO_STDERR
DYLD_PRINT_WEAK_BINDINGS
DYLD_PRINT_WARNINGS
DYLD_PRINT_CS_NOTIFICATIONS
DYLD_PRINT_INTERPOSING
DYLD_PRINT_CODE_SIGNATURES
DYLD_USE_CLOSURES
DYLD_IGNORE_PREBINDING
DYLD_SKIP_MAIN
DYLD_ROOT_PATH and DYLD_PATHS_ROOT appear to be synonyms and allow you to reset the "root" for searching for libraries/frameworks/etc. This is available on macOS/iPhoneSimulator but not iOS.
DYLD_DISABLE_PREFETCH disables the pre-fetching of the content of __DATA and __LINKEDIT segments.
DYLD_PRINT_LIBRARIES_POST_LAUNCH is the same as DYLD_PRINT_LIBRARIES but prints them right after launch has finished.
DYLD_NEW_LOCAL_SHARED_REGIONS and DYLD_NO_FIX_PREBINDING are ignored and don't do anything anymore.
DYLD_PREBIND_DEBUG prints out debug information on why prebinding was not used.
DYLD_PRINT_TO_STDERR only applies to iOS and forces output to stderr (instead of stdout) to help it show up on console logs.
DYLD_PRINT_WEAK_BINDINGS prints debug information on weak bindings.
DYLD_PRINT_WARNINGS prints a bunch of warnings (mostly regards to closures and how they are being used).
DYLD_PRINT_CS_NOTIFICATIONS prints information about the core symbolicator.
DYLD_PRINT_INTERPOSING prints details about interposes that occur.
DYLD_PRINT_CODE_SIGNATURES prints details about code signatures (specifically successes and failures).
DYLD_USE_CLOSURES is a dyld3 feature, but doesn't appear to work for anybody non-internal (need CSR_ALLOW_APPLE_INTERNAL set).
DYLD_IGNORE_PREBINDING has three values ("all", "app", "nonsplit") with nonsplit being the default if a value is not supplied.
DYLD_SKIP_MAIN is an apple only feature used for testing dyld (need CSR_ALLOW_APPLE_INTERNAL set).
Related
I would like to use ProcDump's ability to create minidumps with a custom MINIDUMP_TYPE via the -mc command-line switch to include memory contents beyond MiniDumpNormal.
Unfortunately neither MiniDumpWithFullMemory, MiniDumpWithIndirectlyReferencedMemory, nor MiniDumpWithPrivateReadWriteMemory | MiniDumpWithPrivateWriteCopyMemory seem to have any effect: A nonempty minidump is created without an error being displayed, but a lot smaller than expected and querying the minidump via WinDbg's .dumpdebug functionality does not list any of the aforementioned flags even if explicitly included in the minidump type. It seems as if none of the flags mentioned above have an impact on ProcDump's behavior.
The process in question is a 32-bit process running under 64-bit Windows 10, build 2004. I have tried both procdump.exe and procdump64.exe version 9.0, albeit without the -64 command-line switch since I do not want to include SysWOW64 overhead. I have also tried copying 32-bit and 64-bit versions of dbghelp.dll provided by the most recent Debugging Tools for Windows SDK into the corresponding folders in which procdump.exe and procdump64.exe are located. Finally, I have made sure to pass the minidump type as hexadecimal numbers and any other flags that I have tried seem to be recognized without an issue and are being listed when inspecting the minidump in WinDbg afterwards.
As an example, the invocation procdump.exe -mc 51B25 <process> should create a dump with
0x51B25 = 334629 = (MiniDumpWithDataSegs
| MiniDumpWithProcessThreadData
| MiniDumpWithHandleData
| MiniDumpWithPrivateReadWriteMemory
| MiniDumpWithUnloadedModules
| MiniDumpWithFullMemoryInfo
| MiniDumpWithThreadInfo
| MiniDumpWithTokenInformation
| MiniDumpWithPrivateWriteCopyMemory)
When inspecting the dump in WinDbg, neither MiniDumpWithPrivateReadWriteMemory nor MiniDumpWithPrivateWriteCopyMemory show up in the .dumpdebug information with corresponding memory regions being unavailable. Note that when I create the dump from within the application using MiniDumpWriteDump for demonstration purposes, the flags do show up when using .dumpdebug and the resulting minidump will be significantly larger (under otherwise comparable conditions).
Can someone confirm that ProcDump is indeed ignoring memory-related flags or explain to me what I am doing wrong?
(Writing a MiniPlus dump using the -mp switch does work but does not necessarily include the memory regions of interest.)
I am looking at some old MetaEditor4 / MQL4 code, where a local variable was declared twice:
......
1 int start()
2 {
3 if (1==2)
4 {
5 double myVar = 1;
6 } else
7 {
8 double myVar = 2;
9 }
10 return;
11 }
.......
The compilation process in MetaEditor, version 5.00, build 1601, fails with:
'myVar' - variable already defined in line 8.
If I remove the line 8, the compilation goes well.
My questions are:
1. Is there any option in MetaEditor that tolerates the multiple declaration of a local variable?
2. In previous versions of MetaTrader Terminal 4 / MetaEditor and .MQ4 code: was it possible to declare a local variable more than once in such a situation?
3. The MetaEditor has the version 5.00, build 1601, but the extension of the code is .mq4 and it was installed together with the MetaTrader Terminal software MetaTrader4 ( from FXCM ). Therefore I assume I can still use .MQ4 code with it. Is there any chance to get a pure MQL4 installation from somewhere?
Whenever I install mt4 ( from e.g.: mt4 download), it ends up
with the mt5 installer.
Prologue:
The worlds of MQL4 evolve. One may try to circumvent this fact, but finally, at one's own disappointment, attempts to avoid evolution will sooner or later go in vain.
Having been thrown into a need to re-engineer code-base spanning a few man*decades in size, I can tell you many stories about what worked and what did not.
An "Old code" v/s a New-MQL4.56789
If just one thing ought be taken from this, never try to "circumvent" New-MQL4, but rather review the code and refactor the "Old code" - this is a way safer way to survive ( way longer ).
Yes, there are chances ( zero warrants, just a few chances left temporarily on the table ) the new compiler version will remain able to generate an executable version of the code, but given a new set of rules have already come in the city, the game will not last long.
Ad 1 + 2 )Compiler still tolerates multiple declarations, but not in one scope
If new version of a compiler defined that any variable is declared only relative to it's scope of validity, the serious programmer ought take this as a general principle. The code above actually has other problem, right nailed to the scope-of-validity:
2 ...
3 if ( 1 == 2 ) {
4 ...
5 double myVar = 1; // myVar declared & known |since HERE >
6 ... // masking any other,|known HERE :
7 ... // |known HERE :
8 } else // |till HERE . Undef further
9 {
10 ...
11 double myVar = 2; // myVar declared & known |since HERE >
12 // masking any other,|known HERE :
13 ... // |known HERE :
14 } // |till HERE . Undef further
so, if there were any _global_ scope'd variable with the same name myVar, it will not be "visible" during an existence of locally declared variable, wearing the same name.
Finally, having the code-execution escaped from any of the lines 8 or 14 further, the locally there declared variable double myVar simply ceased to exist anymore and this behaviour is principally correct ( and the "older" compiler releases were tolerating a sort of dangerous habit of side-effects, during years of tolerating scope-of-validity spillover(s), so it was the high time to clean the rules, so as to meet a fair level of C/S standards.
Ad 3) language receives a lot from MQL5, even if not used in MQL4
Yes, MetaEditor will correctly compile a MQL4 code into .mq4 code-execution format, no problem here. Even an auto-update process started to go independently from MT4 Terminal platform (auto-)updates ( so you will quite often see new Help file coming and enforced re-compilation of all your localhost visible .MQ4 assets into updated .EX4 format, so "Do not panic."
Better never install a Broker-agnostic MT4, always go to your Broker's Support and get installation package & help from your Broker. This is business relation you have signed in a contract, so keep these strings as you are going to trade your money on a table they operate under the set Terms & Conditions. Some Brokers have means of platform customisations, so rather benefit from their custom settings that will match their Server-side automation.
It is more a question of economy of R&D efforts. ( May read a lot about language components injected from the MQL5 domain in the IDE Editor MQL4 Help ). This is a natural will of the product design strategy, not to double efforts on a dual-line. Without doubts, there are many details the Help file could be improved and better maintained, the common sense here is to live with the facts and re-learn what newly introduced features remain neutral for the MQL4 code base and what new things may actually help one a lot in aspects, where older compilers were short in powers.
If one objects that some compiler / platform re-design steps were bad, I would agree on a single-thread, platform-critical, potentially blocking, concentration of executing all the CustomIndicator-s in just one SPoF-thread.
But C'est La Vie, until system architects will not review this SPoF, the platform will remain susceptible to crashes from this feature, but the ball is on the other side of the court and a change will have to be implemented there.
the code might be run with 'strict' or non-strict mode.
strict means that variable must be declared within its scope, non-strict - all the mess that you have now.
so put #property strict at the beginning of the file
open a demo account somewhere and install mt4 there. demo can be valid for 30 days only with registration via web-site of a broker or with unlimited and demo opened from mt4 (example - Alpari)
I'm trying my driver with Driver Verifier turned on in Windows 7 x64, and get IRQL_NOT_LESS_OR_EQUAL(0A) bugcheck. From analyze -v info, it seems that the memory page of RtlAnsiCharToUnicodeChar function gets paged out, so calling that function causes bugcheck 0A . RtlAnsiCharToUnicodeChar is an ntoskrnl.exe exported function. Can it really be paged out? If so, how can I prevent it?
On spot debug info screen shot below:
yes. of course - very many ntoskrnl routines in PAGE* section.
RtlAnsiCharToUnicodeChar also paged - read in documentation:
IRQL <= APC_LEVEL
also read about DbgPrintEx routine
DbgPrint and DbgPrintEx can be called at IRQL<=DIRQL. However, Unicode
format codes (%wc and %ws) can be used only at IRQL = PASSIVE_LEVEL.
and
However, the Unicode format codes (%C, %S, %lc, %ls, %wc, %ws, and
%wZ) can only be used with IRQL = PASSIVE_LEVEL.
so if you not use Unicode format you can use DbgPrint or KdPrint(this is macro) at any IRQL but if you use Unicode format - only on PASSIVE_LEVEL or APC_LEVEL (about APC_LEVEL i say by self)
You can try to use the MmLockPagableCodeSection on that specific routine to prevent it being paged out, however it's probably not advisable (and you don't know what dependencies it has, if they're located in pagable sections as well). In any case, make sure you read the documentation thoroughly.
A better approach is to run at Passive/APC level in the first place before invoking the printing function - e.g., by scheduling work item (you can also force lowering the IRQL with KeLowerIrql function but it's not advisable by MSFT).
I am using ar93xx board with pepe2k u-boot. I need to silence all messages printed on the console, as I found there are separate parts print on console:
1- u-boot - can be silenced via its sources
2- early kernel messages starts with something like [0.000000] Linux version x.x.x - ??????
3- later kernel messages - can be silenced via sysctl.conf
4- login - silenced via inittab
My problem is number 2. I tried different ways but with no result, here is the list of some options I tried:
disabling early printk in ar71xx/configxxx
changing CONFIG_CMDLINE="rootfstype=squashfs,jffs2 noinitrd console=null" in ar71xx/configxxx
change bootargs in uboot, console=null
Make uboot with --silence option
none of them was useful, I got confused.
Any help would be greatly appreciated.
Try passing quiet on the kernel command line.
The question is about how to make clang print information on which loops (or other parts of code) have been vectorized. GCC has a command line switch named -ftree-vectorizer-verbose=6 to do this (or -fopt-info-vec in newer versions of GCC), but I couldn't find anything similar for clang. Does clang support this or my only option is to peek in the disassembly ?
clang has following options to print diagnostics related to vectorization:
-Rpass=loop-vectorize identifies loops that were successfully vectorized.
-Rpass-missed=loop-vectorize identifies loops that failed vectorization and indicates if vectorization was specified.
-Rpass-analysis=loop-vectorize identifies the statements that caused vectorization to fail.
Source: http://llvm.org/docs/Vectorizers.html
Looking through the clang source code, there are a couple vectorization passes in Transforms/Vectorize:
BBVectorize
LoopVectorize
SLPVectorize
The last three don't seem to have any arguments that will print things. But in inside BBVectorize there are a couple of options for printing things when clang is built debug:
bb-vectorize-debug-instruction-examination - When debugging is enabled, output information on the instruction-examination process
bb-vectorize-debug-candidate-selection - When debugging is enabled, output information on the candidate-selection process
bb-vectorize-debug-pair-selection - When debugging is enabled, output information on the pair-selection process
bb-vectorize-debug-cycle-check - When debugging is enabled, output information on the cycle-checking process
bb-vectorize-debug-print-after-every-pair -When debugging is enabled, dump the basic block after every pair is fused
That looks like it's about it.