Is there any workable PoC of clang stack instrumentation with arm64 MTE?
I tried enable clang stack instrumentation with arm64 MTE but faced with bug presented in clang which causes false positive MTE reports. I reported issue in LLVM bugzilla - https://bugs.llvm.org/show_bug.cgi?id=51362.
Just interesting, does someone successfully run clang stack instrumentation with arm64 MTE?
Whole stack should be inited with some default allocation tag:
char *sp = alloc_kernel_stack();
/* set the logical tag */
sp = insert_random_tag(sp);
for (i = 0; i < STACK_SIZE; i += 16) {
/* set the allocation tag */
set_tag(sp);
sp += i;
}
This will fix MTE false positive reports. More details can be found here - https://bugs.llvm.org/show_bug.cgi?id=51362
Related
#pragma message is implemented in Clang as warning.
Is there any way to disable the warning only for this pragma, so it will be have like MS Visual Studio, or some other way to give informational messages from code ?
(I need an answer as an end user with a given Clang, I cannot re-compile the Clang itself on this project)
I realize this post is a year old and the OP probably already found his answer but since I was looking for the answer myself I thought I may as well include the info here.
From the Clang user's manual:
https://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-pragmas
The pragma may control any warning that can be used from the command line. Warnings may be set to ignored, warning, error, or fatal.
Attempting to set the class to something other than the above:
#pragma clang diagnostic push
#pragma clang diagnostic note "-W#pragma-messages"
#pragma message "HELLO!"
#pragma clang diagnostic pop
int main(int argc, char **argv)
{
}
Results in a warning showing the same options:
/tmp/test.cc:3:26: warning: pragma diagnostic expected 'error', 'warning', 'ignored', 'fatal', 'push', or 'pop' [-Wunknown-pragmas]
#pragma clang diagnostic note "-W#pragma-messages"
^
/tmp/test.cc:4:9: warning: HELLO! [-W#pragma-messages]
#pragma message "HELLO!"
^
2 warnings generated.
So it appears that as of Clang 5.0 there is no way to treat the message as informational instead of as a warning.
I've got a function with such part of code:
if (CGFLOAT_IS_DOUBLE) {
return fabs(x / y);
} else {
return fabsf(x / y);
}
However with new Xcode I'm obtaining a warning here:
Absolute value function 'fabsf' given an argument of type 'double' but
has parameter of type 'float' which may cause truncation of value
The warning wasn't visible in Xcode 6, but in Xcode 7 Beta it is.
With such wrapping, I'm moreover sure that the values are float type. Now the question is how to suppress the warning?
I've tried with many Clang flags, ended on most general:
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wall"
// above code
#pragma clang diagnostic pop
But it doesn't help (odd?). "-W" also doesn't help. Any tip..?
I don't want to cast, create extra float variables nor anything similar. I just want to silence the warning.
I've recently come across with double return statement (one of them was added by mistake) in our project and wondering why compiler doesn't show a warning for that?!
Ok, I added -Wunreachable-code to other warning flags, but still no luck.
Got warning - with a code to execute after return statement:
Didn't get warning but still second return statement will never be executed.
Even if I add something like this, still no warning
Is there extra warning flag for that, or compiler isn't smart enough?
Good catch!
-Wunreachable-code does not report a warning and there is no other warning flag which would do.
Not even the Static Analyzer catches this mistake!
(Tested with XCode 6.1 GM 2)
Wrap your code in pragma flags that will suppress that warning between the push and pop
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunreachable-code"
//Your code goes here
#pragma GCC diagnostic pop
Use -Wno-unreachable-code for your file in Build Phases.
Try this...
-(NSString*) makeSomeStringForMe {
NSString *someString = #"some string";
return someString;
}
I am familiar with #pragma mark objective-c / xcode / ios development and that it is useful for finding sections of code.
However, I am wondering if there are other keywords other than 'mark'. Like, can you do #pragma somethingelse? Thanks in advance!
First, some examples:
You can control diagnostics:
http://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-pragmas
And from the same link:
clang supports the Microsoft "#pragma pack" feature for controlling record layout. GCC also contains support for this feature, however where MSVC and GCC are incompatible clang follows the MSVC definition.
clang supports the Microsoft #pragma comment(lib, "foo.lib") feature for automatically linking against the specified library. Currently this feature only works with the Visual C++ linker.
clang supports the Microsoft #pragma comment(linker, "/flag:foo") feature for adding linker flags to COFF object files. The user is responsible for ensuring that the linker understands the flags.
The second and third from that list won't apply to your iOS code, though.
Wikipedia [link] says that clang supports #pragma once, too.
And finally, here's a link to the clang API documentation for the pragma handling code. You can browse from there to see everything else. In particular, TokenKinds.def describes all the accepted tokens, so presumably it's complete:
#pragma unused
#pragma GCC visibility [push/pop]
#pragma pack [value/show/push/pop/etc/etc/etc]
#pragma clang __debug parser_crash
#pragma clang __debug captured
#pragma ms_struct [on/off]
#pragma align [native/natural/mac68k/power/reset]
#pragma weak [identifier]
#pragma weak [identifier = identifier] // alias
#pragma redefine_extname [identifier identifier]
#pragma STDC FP_CONTRACT
#pragma OPENCL EXTENSION
#pragma omp [...]
#pragma detect_mismatch
#pragma comment
The parsing code, found in ParsePragma.cpp, seems to indicate that not all of them are implemented, even if the front-end accepts them, though.
Yes. It's often used for implementation defined directives, but there are a few which are defined in C.
6.10.6 Pragma directive Semantics 1
A preprocessing directive of the form # pragma pp-tokensopt new-line where the preprocessing token STDC does not immediately
follow pragma in the directive (prior to any macro replacement)
causes the implementation to behave in an implementation-defined
manner. The behavior might cause translation to fail or cause the
translator or the resulting program to behave in a non-conforming
manner. Any such pragma that is not recognized by the implementation
is ignored.
If the preprocessing token STDC does immediately follow pragma in the directive (prior to any macro replacement), then no macro
replacement is performed on the directive, and the directive shall
have one of the following forms whose meanings are described
elsewhere:
#pragma STDC FP_CONTRACT on-off-switch
#pragma STDC FENV_ACCESS on-off-switch
#pragma STDC CX_LIMITED_RANGE on-off-switch
`on-off-switch`: one of `ON OFF DEFAULT`
Carl Norum's answer covered examples of implementation defined directives well. For a complete list, you should refer to your compiler's documentation.
I'm relatively new to iOS development, and am trying to implement CocoaLumberjack logging.
I downloaded the latest source from https://github.com/robbiehanson/CocoaLumberjack, have included the required files in my project, made the necessary code changes, and am getting the run-time linker error that follows below.
The environment is Xcode 4.2 Build 4C199, with the project Target set to Device=iPad and DeploymentTarget=4.3. The project was initially written using retain/release, so I left the original source as-is, adding the compiler flag "-fobjc-arc" for the Lumberjack files I'm using: DDFileLogger.m, DDLog.m and DDTTYLogger.m.
The console output is:
GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Fri Sep 16 06:56:50 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i386-apple-darwin --target=arm-apple-darwin".tty /dev/ttys001
sharedlibrary apply-load-rules all
target remote-mobile /tmp/.XcodeGDBRemote-10996-56
Switching to remote-macosx protocol
mem 0x1000 0x3fffffff cache
mem 0x40000000 0xffffffff none
mem 0x00000000 0x0fff none
[Switching to process 11779 thread 0x2e03]
[Switching to process 11779 thread 0x2e03]
dyld: lazy symbol binding failed: Symbol not found: _objc_storeStrong
Referenced from: /var/mobile/Applications/32E4EEB9-765E-4C72-83C8-F5707253AA99/Demo.app/Demo
Expected in: /usr/lib/libobjc.A.dylib
dyld: Symbol not found: _objc_storeStrong
Referenced from: /var/mobile/Applications/32E4EEB9-765E-4C72-83C8-F5707253AA99/Demo.app/Demo
Expected in: /usr/lib/libobjc.A.dylib
warning: Attempting to create USE_BLOCK_IN_FRAME variable with block that isn't in the frame.
(gdb)
My project initializes the environment as follows, where fileLogger is an instance variable defined in the corresponding AppDelegate.h file:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
/*
* Configure the Lumberjack logging framework (we'll use it instead of NSLog)
*/
// the TTY logger is the Xcode console
[DDLog addLogger:[DDTTYLogger sharedInstance]];
// we'll also use a file logger
fileLogger = [[DDFileLogger alloc] init];
fileLogger.rollingFrequency = 60 * 60 * 24; // 24 hour rolling
fileLogger.logFileManager.maximumNumberOfLogFiles = 7;
[DDLog addLogger:fileLogger];
// Override point for customization after application launch.
DDLogInfo(#"didFinishLaunchingWithOptions: entered");
// create instance of the view controller
MainViewController *aViewController = [[MainViewController alloc]
initWithNibName:#"MainView" bundle:nil];
self.mainViewController = aViewController; // same as: [self setMainViewController:aViewController];
[aViewController release];
// Add the main view controller's view to the window and display.
self.window.rootViewController = self.mainViewController;
[self.window makeKeyAndVisible];
return YES;
}
Has anyone encountered this problem, and know of a solution or workaround? Is what I'm doing even possible... having mixed ARC and non-ARC files in a project?
For future reference, this seems to be a shortcoming of the current Xcode toolchain that seems to forget to include the ARC library when the currently built target has the ARC support turned off (and uses ARC-enabled static libraries). You can easily force the linker to include the library using the -fobjc-arc flag, see this related question for a complete description.
I just heard back from one of the CocoaLumberjack developers, this is what he said:
There seems to be a bug in (maybe) the LLVM compiler. Here's what I've
discovered:
If you have an Xcode project without ARC turned on by default, and you
have a file that uses ARC (via -fobjc-arc), and that file attempts to
alloc/init stuff within '+ (void)initialize', then it will blow up at
runtime.
It seems to work, however, if you convert the project to ARC...
EDIT: Additional information from the developer:
The 1.2.3 tag can be used without ARC.
You can grab an archive from here:
https://github.com/robbiehanson/CocoaLumberjack/tags