Evaluating expressions involving sequences of calls with non-trivial intermediate values produce errors like "Attempt to take address of value not located in memory." or, in other cases, gdb reporting SIGSEGV in the inferior. To reproduce: echo 'struct S {}; S f() { return S(); } S g(const S &s) { return s; } int main() { S s = g(f()); }' | g++ -xc++ -o x -g - gdb -ex 'b main' -ex run -ex 'p g(f())' ./x My guess is that the result of the call is transfered from the inferior into gdb, but not "moved back" for further processing. The problem can be partially worked around by manually disentangling the calls and "poking" the intermediate results back into the inferior using something like def makeValue(type, init): gdb.execute("set $d = (%s*)malloc(sizeof(%s))" % (type, type)) gdb.execute("set *$d = {%s}" % init) return gdb.parse_and_eval("$d").dereference()
Are you saying that the same example sometimes crashes the inferior, while sometimes results in the "Attempt to take address of value not located in memory." error, or do you need a different reproducer to cause SIGSEGV crash in the inferior? If the latter, do you have such a reproducer?
The example given always produces "Attempt to take address of value not located in memory." as far as I can tell. The SIGSEGV reports have been showing up in a somewhat more complex setup involving Qt Creator's pretty-printers for QObject and QModelIndex that also uses cascaded inferior calls. I believe the problem is the same, though and would like to save me the trouble to cut this down to something that's reproducible without a lot of external dependencies. Sorry for the confusion.
Created attachment 4913 [details] test case
While the example mentioned can be fixed by setting the lval of the value returned by call_function_by_hand() lval_memory further nesting does not work. example attached.
This issue was also discussed here: http://www.cygwin.com/ml/gdb-patches/2010-08/msg00053.html
I might be wrong, but I am inclined to think that this is also linked to bad calling convention similar to PR/13403.
I've checked this against GDB 7.12.50 and it works fine.