I feel rather silly today. Even though I knew about virtual address space randomisation in newer Linux kernels, it never struck me that I should disable it to get a reproducible debugging session with predictable breakpoint conditionals. My silly workaround was to use this patch:
Index: tree-ssa-operands.c =================================================================== --- tree-ssa-operands.c (revision 109196) +++ tree-ssa-operands.c (working copy) @@ -1460,6 +1460,16 @@ get_call_expr_operands (tree stmt, tree tree op; int call_flags = call_expr_flags (expr); + if (strcmp (lang_hooks.decl_printable_name (current_function_decl, 2), + "of") == 0) + { + const char *called_f + = lang_hooks.decl_printable_name (TREE_OPERAND (TREE_OPERAND (stmt, 0), + 0), 2); + if (strcmp (called_f, "_Jv_ThrowBadArrayIndex") == 0) + printf ("Hello \"_Jv_ThrowBadArrayIndex\"!\n"); + } + if (!bitmap_empty_p (call_clobbered_vars)) { /* A 'pure' or a 'const' functions never call clobber anything. and then put a breakpoint at the "printf" to get the debugger to stop the compiler process while processing the operands for the statement I was interested in. Thanks to Mike Stump, we now have a page in the GCC Wiki that explains this problem and how to avoid it. Putting in the desired breakpoint is very simple now and avoids unnecessarily kludgy patches that contaminate the tree: (gdb) b tree-ssa-operands.c:1463 Breakpoint 1 at 0x80d1f3f: file /extra/src/gcjx/gcc/gcc/tree-ssa-operands.c, line 1463. (gdb) cond 1 stmt==0xb7c27fc8Cool! Now all that is left is to use this breakpoint to figure out what the actual problem is that caused us to fire up a debugger.