This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC/ia64] memory error when reading wrong core file


Thanks for taking the time to test my patch!

> this specific problem gets also fixed by:
> 	[patch] Sanity check PIE displacement (like the PIC one)
> 	http://sourceware.org/ml/gdb-patches/2010-02/msg00000.html
[...]
> Still I think you have found a problem of its own which should be fixed
> anyway.

Agreed.

> When some memory access fails it should be IMO printed as it is some sort of
> incorrect operation.  Therefore I would prefer the attached patch producing:

Agreed as well.

> Just if there exists catch_errors shouldn't it be used instead of TRY_CATCH?

TRY_CATCH was introduced after catch_error, and I *think* that it was
intended as a simpler way to call some code while being able to handle
gdb exceptions.  I don't know about others, but I do not really like
the catch_errors/catch_exceptions interface - I think it's awkward to
use: You almost always have to define an "args" struct type that contains
the arguments, and most of the time a developer will also separate
the stub (the function called by catch_exceptions which unmarshalls the
function arguments) from the real implementation.  TRY_CATCH greatly
simplifies the use process, which is why I'm trying to use it in preference
to catch errors as much as I can.

The downside, as you are pointing out, is the lack of error message
when an exception is raised. The attached patch fixes this.

That made me wonder, however, why we have 2 routines to do the exception
printing.  There's probably some cleanup we could do, there...

gdb/ChangeLog:

        * solib-svr4.c (solib_svr4_r_map): catch and print all exception
        errors while reading the inferior memory, and return zero if
        an exception was raised.

This patch should be strictly equivalent to yours, I believe. I've tested
it against the testcase described in this thread as well as the rest of
AdaCore's testsuite.

-- 
Joel
diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
index e497364..dc9a685 100644
--- a/gdb/solib-svr4.c
+++ b/gdb/solib-svr4.c
@@ -835,9 +835,16 @@ solib_svr4_r_map (struct svr4_info *info)
 {
   struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
   struct type *ptr_type = builtin_type (target_gdbarch)->builtin_data_ptr;
+  CORE_ADDR addr = 0;
+  volatile struct gdb_exception ex;
 
-  return read_memory_typed_address (info->debug_base + lmo->r_map_offset,
-				    ptr_type);
+  TRY_CATCH (ex, RETURN_MASK_ERROR)
+    {
+      addr = read_memory_typed_address (info->debug_base + lmo->r_map_offset,
+                                        ptr_type);
+    }
+  exception_print (gdb_stderr, ex);
+  return addr;
 }
 
 /* Find r_brk from the inferior's debug base.  */

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]