I'm using Xcode/lldb to debug some C code. But I get this error
(lldb) p (int)g_list_position(start, next)
(int) $0 = 1
(lldb) p (int)g_list_position(start, this)
error: expected unqualified-id
error: invalid use of 'this' outside of a non-static member function
So apparently lldb things "this" is a reference to a class, in spite of it being a perfectly valid var in C (and its value is 0, as it should be). Is there some way to escape this name in lldb?
No, the expression evaluator in lldb wraps your expression (at at a source level) with some C++ to pass the arguments in. The only suggestion I can think of is to get the address in the this pointer and put that in the expression explicitly. It's a goal of the expression evaluation that you can copy a line of source in your program and execute it as an expression in lldb .. but this is a corner case where that does not work - variables in C that are reserved words in C++.
Related
This might be a weird question, but some programs written in Go won't run on my MacBook Pro after MacOS Catalina upgrade.
However a basic "Hello World" program runs, but then I am using the writing a program using net/http package I get the following error:
Note: The programs are correct, they run fine inside a Docker container
Output (IntelliJ):
# runtime/cgo
In file included from gcc_darwin_amd64.c:6:
/usr/local/include/pthread.h:331:6: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
/usr/local/include/pthread.h:200:2: note: expanded from macro '_PTHREAD_SWIFT_IMPORTER_NULLABILITY_COMPAT'
/usr/local/include/pthread.h:331:6: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
/usr/local/include/pthread.h:200:34: note: expanded from macro '_PTHREAD_SWIFT_IMPORTER_NULLABILITY_COMPAT'
/usr/local/include/pthread.h:540:6: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
/usr/local/include/pthread.h:200:2: note: expanded from macro '_PTHREAD_SWIFT_IMPORTER_NULLABILITY_COMPAT'
/usr/local/include/pthread.h:540:6: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
/usr/local/include/pthread.h:200:34: note: expanded from macro '_PTHREAD_SWIFT_IMPORTER_NULLABILITY_COMPAT'
Things that I have already tried:
Reinstall go
Reinstall xcode
Check if GOPATH & GOROOT are properly set
Used:
MacOS version - Catalina 10.15.6
Go version - go1.15.2 darwin/amd64
Type xcode-select -print-path in terminal window and check your installed directory. In my case the output was: /Applications/Xcode.app/Contents/Developer
If it's the same case then using the following command on your terminal can fix things:
sudo xcode-select --switch /Library/Developer/CommandLineTools
Another option is to use CGO_CPPFLAGS as mentioned in this issue, but it would work within the session:
export CGO_CPPFLAGS="-Wno-error -Wno-nullability-completeness -Wno-expansion-to-defined -Wno-builtin-requires-header"
Sadly, none of the tryouts worked.
I have been using IntelliJ IDEA Ultimate for sometime now.. so I tried to setup Go SDK, GOROOT and GOPATH using the IDE (just a thought came to my mind).
I uninstalled/deleted everything related to Go on my MacBook.
Then I installed the Go plugin on IntelliJ IDEA and as expected it prompted that Go SDK is not available, neither GOROOT and GOPATH are set.
I followed the instructions and IntelliJ IDEA took care of the rest!
It downloaded and installed Go SDK, asked me to select GOPATH, it indexed stuff and now every thing is working like a charm!
This is a bug in the <pthread.h> that ships with macOS tools:
This macro is even bogus for more than one reason! The definition in <pthread.h> is this:
#define _PTHREAD_SWIFT_IMPORTER_NULLABILITY_COMPAT \
defined(SWIFT_CLASS_EXTRA) && (!defined(SWIFT_SDK_OVERLAY_PTHREAD_EPOCH) || (SWIFT_SDK_OVERLAY_PTHREAD_EPOCH < 1))
The macro expansion is not properly parenthesized. The macro is used this way in the same file:
#if !_PTHREAD_SWIFT_IMPORTER_NULLABILITY_COMPAT
Which expands to:
#if !defined(SWIFT_CLASS_EXTRA) && (!defined(SWIFT_SDK_OVERLAY_PTHREAD_EPOCH) || (SWIFT_SDK_OVERLAY_PTHREAD_EPOCH < 1))
The ! only applies to the first test defined(SWIFT_CLASS_EXTRA) not to the whole boolean expression.
The compiler does not detect this problem, it just complains about the defined preprocessor operator coming from a macro expansion, which has undefined behavior as specified in the C Standard:
6.10.1 Conditional inclusion
[...]
Constraints
1 The expression that controls conditional inclusion shall be an integer constant expression except that: identifiers (including those lexically identical to keywords) are interpreted as described below; and it may contain unary operator expressions of the form
defined identifier
or
defined ( identifier )
which evaluate to 1 if the identifier is currently defined as a macro name (that is, if it is predefined or if it has been the subject of a #define preprocessing directive without an intervening #undef directive with the same subject identifier), 0 if it is not.
2 Each preprocessing token that remains (in the list of preprocessing tokens that will become the controlling expression) after all macro replacements have occurred shall be in the lexical form of a token (6.4).
Semantics
3 Preprocessing directives of the forms
# if constant-expression new-line groupopt
# elif constant-expression new-line groupopt
check whether the controlling constant expression evaluates to nonzero.
4 Prior to evaluation, macro invocations in the list of preprocessing tokens that will become the controlling constant expression are replaced (except for those macro names modified by the defined unary operator), just as in normal text. If the token defined is generated as a result of this replacement process or use of the defined unary operator does not match one of the two specified forms prior to macro replacement, the behavior is undefined. After all replacements due to macro expansion and the defined unary operator have been performed, all remaining identifiers (including those lexically identical to keywords) are replaced with the pp-number 0, and then each preprocessing token is converted into a token. The resulting tokens compose the controlling constant expression which is evaluated according to the rules of 6.6. For the purposes of this token conversion and evaluation, all signed integer types and all unsigned integer types act as if they have the same representation as, respectively, the types intmax_t and uintmax_t defined in the header <stdint.h>. This includes interpreting character constants, which may involve converting escape sequences into execution character set members. Whether the numeric value for these character constants matches the value obtained when an identical character constant occurs in an expression (other than within a #if or #elif directive) is implementation-defined. Also, whether a single-character character constant may have a negative value is implementation-defined.
This relevant phrase is If the token defined is generated as a result of this replacement process or use of the defined unary operator does not match one of the two specified forms prior to macro replacement, the behavior is undefined.
It is unclear if generated just means produced as part of the macro expansion or more specifically produced by token pasting. clang seems to consider that any defined token produced coming from a macro expansion has undefined behavior in a #if controlling expression.
For both reasons, this seems to be a bug in <pthread.h> for Apple to fix.
When I am declaring a method like this:
- (void)doAnythingWithThisBlock:(void(^)(NSString *, ... NS_REQUIRES_NIL_TERMINATION))AnythingBlock;
It is giving compilation error:
Expected ')'
but when I am declaring it like this:
- (void)doAnythingWithThisBlock:(void(^)(NSString *, ...))AnythingBlock;
It compiles fine and works as expected
Cannot we use - NS_REQUIRES_NIL_TERMINATION while declaring a method which accepts input as block with variable number of arguments?
I am trying it in XCode 4.2
I guess NS_REQUIRES_NIL_TERMINATION is only for method declarations 1
However you can try to typedef your block to certain type and pass it as an argument: may be clang will eat it then?
Why gives this code in ruby18 and ruby19 a syntax error:
a (b.c do;end)
I would have expected it to mean the following. A call to the method a with one argument. The parentheses after the space are not method argument parentheses, but only normal parentheses like you can put almost everywhere. The argument is the return value of the call to the method c on the object b with a block.
All of the following are however interpreted as syntactically correct by ruby18. Only the first of these examples is treated as syntactically incorrect by ruby19.
a (b do;end)
and:
a (b.c {})
and:
(b.c do;end)
Remove the space in between the method name and the (. Ruby used to warn that this was dodgy and it does seem to throw ruby 1.9 off in some cases.
I am trying to get this Ruby inline C code http://pastie.org/2825882 to work. The code works in vanilla C, but here I get errors and warnings. What causes this error?
./backtrack_inline.rb:67: error: lvalue required as unary '&' operand
Also, why do I get the following error?
./backtrack_inline.rb:73: error: too few arguments to function 'backtrack'
Inspecting the resulting C code ( http://pastie.org/2826036) I fail to see anything wrong with the arguments. But I do also get the following warnings:
./backtrack_inline.rb:73: warning: passing argument 1 of 'backtrack' makes integer from pointer without a cast
./backtrack_inline.rb:73: warning: passing argument 2 of 'backtrack' makes integer from pointer without a cast
./backtrack_inline.rb:73: warning: passing argument 3 of 'backtrack' makes integer from pointer without a cast
Starting with this:
./backtrack_inline.rb:73: error: too few arguments to function 'backtrack'
If you look at your generated code, the backtrack function is defined on line 29:
static VALUE backtrack(VALUE self, VALUE _ss, VALUE _s, VALUE _p, VALUE _mm, VALUE _ins, VALUE _del) { ... }
It has seven arguments, the original six, plus VALUE self as it has been converted into a method on the Scan class.
The call to this function, on line 67 looks like this:
end = backtrack(ss, s, p, mm, ins, del);
It has only six arguments. RubyInline doesn't convert this to a call to a method on the object, it simply copies it verbatim. This is also where the warnings about makes integer from pointer without a cast come from: the function definition has been converted to take VALUEs, but you're calling with the original types.
The error message says that the error is from line 73 in backtrack_inline.rb because of the directive on line 54 of the generated code:
# line 61 "./backtrack_inline.rb"
which basically tells the compiler to "reset" its line and file values for errors, and treat the next line (55) as being line 61 in the file ./backtrack_inline.rb. The actual line is 67, 12 ahead of 55, but the compiler reports it as being 73, 12 ahead of 61 (the value it was reset to) and from a differnt file. This technique doesn't really work in this case as it doesn't take into account the extra lines added by RubyInline. The actual line in the source is 69.
A simple fix for this is to change the definition of the backtrack function to be just a C function rather than add it as a method on the object. Change builder.c to builder.prefix (on line 38 of your Ruby file). This won't work if you want to have backtrack available as a method on the object in Ruby. If that's the case you might need create another function to be the method, which then wraps the "real" backtrack function.
Next, looking at
./backtrack_inline.rb:67: error: lvalue required as unary '&' operand
This actually refers to line 61 of the generated code, which looks like:
char* s = StringValuePtr(rb_iv_get(self, "#seq"));
StringValuePtr is a macro which is defined as:
#define StringValue(v) rb_string_value(&(v))
This is where the & in lvalue required as unary '&' operand comes from. You need to add a local variable to be the lvalue:
VALUE seq = rb_iv_get(self, "#seq");
char* s = StringValuePtr(seq);
In my case (Mac OS X Snow Leopard, Ruby 1.9.3-p0, RubyInline 3.11.0) these two changes made the script run without errors, but gave the warning:
backtrack_inline.rb:47: warning: implicit conversion shortens 64-bit value into a 32-bit value
This actually refers to line 46 of the ruby file:
return (s - ss) - 1;
s and ss are char *, i.e. 64 bit pointers (on this machine), and the return type of the function is int - 32 bits. Adding an explicit cast fixed this:
return (int)((s - ss) - 1);
It now runs cleanly:
ruby-inline $ ruby backtrack_inline.rb
14
ruby-inline $
(I hope 14 is the correct answer!)
Here's a version of the script with these changes.
OK, the question was also answered at Ruby Forum:
http://www.ruby-forum.com/topic/2959614
Ok... thought a bit more about this.
you are calling a variable end. While this isn't a reserved word in C - and ruby shouldn't be looking at it... perhaps ruby is getting confused?
I'd suggest you have a go at renaming it just in case. Worthwhile trying even just to rule it out.
Say, I have two adjacent functions subfunc() and main() in the Mach-O executable and want to disassemble all instructions from subfunc() to main()+0x10.
I know I can cast functions to addresses using `(void(*)())subfunc` - isn't there an easier way?
My attempt is as follows, but I get the error message below:
dis -s `(void(*)())subfunc` -e `(void(*)())main+0x10`
error: error: arithmetic on a pointer to the function type 'void ()'
How can I fix this?
This appears to be the correct syntax:
dis --start-address `(void(*)())main` --end-address `(void(*)())main`+0x10
The very small difference between this syntax and the variant you tried is that the +0x10 offset goes outside the backtick characters, i.e. the offset goes after the closing backtick.
FWIW this variant also appears to work correctly:
dis --start-address `(void(*)())main` --end-address 0x10+`(void(*)())main`
Discovery process:
I was unfamiliar with the "backtick" + function cast that you described in your original question so that was a very helpful starting point.
In my case I was trying to set a breakpoint at a function offset inside a shared library and got about as far as this before my search landed me on your question:
breakpoint set --shlib libexample.dylib --address `((void*)some_function)+81`
error: error: function 'some_function' with unknown type must be given a function type
error: 1 errors parsing expression
The use of your function cast hint met the "function type" requirement stated in the error message so I was next able to get to:
print (void(*)())some_function
(void (*)()) $38 = 0x00000001230094d0 (libexample.dylib`some_function)
I then tried the backtick variant which appeared to work but I wanted the value to be displayed in hexadecimal:
print `(void(*)())some_function`
(long) $2 = 4882207952
But when I tried to use the -f hex format option with print I got an error:
print -f hex `(void(*)())some_function`
error: use of undeclared identifier 'f'
error: 1 errors parsing expression
Eventually I noticed the comment 'print' is an abbreviation for 'expression --' at the bottom of the help print output and realised that means it's (apparently?) not possible to use an alternative display format with print because it gets converted into expression -- -f hex ... which is not valid syntax.
Eventually I figured out the required placement & combination of command name, display format and "--" to make it display as desired:
expression -f hex -- `(void(*)())some_function`
(long) $7 = 0x00000001230094d0
For no particular reason (that I can remember) it was at this point I tried placing the offset outside the backticks and it worked!
expression -f hex -- `(void(*)())some_function`+81
(long) $12 = 0x0000000123009521
And it still worked when I tried it with a breakpoint:
breakpoint set --shlib libexample.dylib --address `(void(*)())some_function`+81
Breakpoint 6: where = libexample.dylib`some_function + 81, address = 0x0000000123009521
Then I verified that it also worked with the dis command from your original question:
dis --start-address `(void(*)())some_function` --end-address `(void(*)())some_function`+81
And confirmed that the bare function name was not sufficient:
dis --start-address some_function --end-address `(void(*)())some_function`+81
error: address expression "some_function" evaluation failed
I also re-confirmed that the offset being between the backticks did not work:
dis --start-address `(void(*)())some_function` --end-address `(void(*)())some_function+1`
error: error: arithmetic on a pointer to the function type 'void ()'
error: 1 errors parsing expression
It was at this point that I realised I was able to parse the error message (as it was presumably intended):
[arithmetic on a pointer] [to the function type] ['void ()']
The underlying issue being "arithmetic on a pointer"...
Which further research shows is both "undefined on pointers to function types" and available as a gcc extension:
https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html
Why is it not allowed to perform arithmetic operations on function pointers?
Should clang and gcc produce a diagnostic message when a program does pointer arithmetic on a function pointer?
Incrementing function pointers
Function pointer arithmetic
How to print the address of a function?
https://github.com/llvm/llvm-project/blob/f804bd586ee58199db4cfb2da8e9ef067425900b/clang/test/Sema/pointer-addition.c
https://reviews.llvm.org/D37042
Which brings us back to the comments by #JasonMolenda & #JimIngham and how the function pointer arithmetic parsing is special-cased.
To my mind the "error: arithmetic on a pointer to the function type..." message you received is at best poor UX & at worst a bug--given that lldb itself essentially displays address references in that manner:
0x1230094f9: jle 0x123009cc2 ; some_function + 2034
I feel similarly about libexample.dylib`some_function + 81 being displayed but AFAICT not being parsed.
In conclusion, this form works:
`(void(*)())some_function`+0x10
Now I just need to figure out why some_function isn't doing what I think it should... :)