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

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

Hi Joel,

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
which produces

(gdb) core core
warning: core file may not match specified executable file.
[New Thread 5437]
warning: PIE (Position Independent Executable) displacement 0xffffffffffffe580 is not aligned to the minimal page size 0x4000 for "/root/wrong-core-for-exe/call_crash" (wrong executable or version mismatch?)
Reading symbols from /lib/ld-linux-ia64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux-ia64.so.2
warning: PIE (Position Independent Executable) displacement 0xffffffffffffe580 is not aligned to the minimal page size 0x4000 for "/root/wrong-core-for-exe/call_crash" (wrong executable or version mismatch?)
Core was generated by `./crash'.
Program terminated with signal 6, Aborted.
#0  0xa000000000010640 in __kernel_syscall_via_break ()

Still I think you have found a problem of its own which should be fixed
anyway.


On Fri, 29 Jan 2010 17:02:22 +0100, Joel Brobecker wrote:
> This explains the change of behavior, which is not entirely unreasonable.
> That being said, I think that the new behavior is less useful for the user.

I think the PASS->FAIL turn is in fact just accident, it could even turn
FAIL->PASS etc.


> What I suggest, is to catch all errors while trying to read the shared
> library map, and try to continue without.  Something like the attached?
> 
> It gives me the following output:
> 
>     (gdb) core core
>     warning: exec file is newer than core file.
>     [New Thread 5437]
>     warning: Can't read pathname for load map: Input/output error.
>     Reading symbols from /lib/tls/libc.so.6.1...(no debugging symbols found)...done.
>     Loaded symbols for /lib/tls/libc.so.6.1
>     Reading symbols from /lib/ld-linux-ia64.so.2...(no debugging symbols found)...done.
>     Loaded symbols for /lib/ld-linux-ia64.so.2
>     Core was generated by `./crash'.
>     Program terminated with signal 6, Aborted.
>     #0  0xa000000000010640 in __kernel_syscall_via_break ()

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:

(gdb) core core
warning: core file may not match specified executable file.
[New Thread 5437]
Cannot access memory at address 0x1000000000009
Cannot access memory at address 0x1000000000009
Cannot access memory at address 0x1000000000009
Reading symbols from /lib/tls/libc.so.6.1...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/libc.so.6.1
Reading symbols from /lib/ld-linux-ia64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux-ia64.so.2
Cannot access memory at address 0x1000000000009
Core was generated by `./crash'.
Program terminated with signal 6, Aborted.
#0  0xa000000000010640 in __kernel_syscall_via_break ()

(this dump has been made up a bit)


> As mentioned on IRC, I could not test this on ia64-linux with the official
> testsuite, as the testsuite run immediately crashes the two machines on
> which I tried (after which I was firmly prohibited from making any additional
> attempt on any other machines).

Tested your original patch on RHEL-5.4 ia64 with no regressions using:
make check-single RUNTESTFLAGS="--ignore 'watch-vfork.exp interrupt.exp'"


Tested the patch attached below on {x86_64,x86_64-m32,i686}-fedora12-linux-gnu
(as it is IMO fully arch-independent).

Technical details:
This patch could be made more simple just by extending your patch by:
	print_any_exception (gdb_stderr, errstring, exception);

Just if there exists catch_errors shouldn't it be used instead of TRY_CATCH?
Moreover catch_errors is considered deprecated in favor of catch_exceptions.
But I am open for inlining catch_errors there as you did, with that new
print_any_exception call, if you agree.


Moreover this patch is not required if a new patch for PAGESIZE sanity checking
PIE displacement



Thanks,
Jan


2010-02-01  Jan Kratochvil  <jan.kratochvil@redhat.com>
	    Joel Brobecker  <brobecker@adacore.com>

	* solib-svr4.c
	(struct solib_svr4_r_map_args): New.
	(solib_svr4_r_map): Call solib_svr4_r_map_stub and move the former
	code content to ...
	(solib_svr4_r_map_stub): ... a new function.

--- a/gdb/solib-svr4.c
+++ b/gdb/solib-svr4.c
@@ -823,6 +823,30 @@ locate_base (struct svr4_info *info)
   return info->debug_base;
 }
 
+/* Arguments for catch_exceptions's call of solib_svr4_r_map_stub.  */
+
+struct solib_svr4_r_map_args
+  {
+    struct svr4_info *info;
+    CORE_ADDR retval;
+  };
+
+/* Stub interface for catch_exceptions's called from solib_svr4_r_map.  */
+
+static int
+solib_svr4_r_map_stub (struct ui_out *ui_out, void *args1)
+{
+  struct solib_svr4_r_map_args *args = args1;
+  struct svr4_info *info = args->info;
+  struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
+  struct type *ptr_type = builtin_type (target_gdbarch)->builtin_data_ptr;
+  
+  args->retval = read_memory_typed_address ((info->debug_base
+					     + lmo->r_map_offset),
+					    ptr_type);
+  return 1;
+}
+
 /* Find the first element in the inferior's dynamic link map, and
    return its address in the inferior.
 
@@ -833,11 +857,16 @@ locate_base (struct svr4_info *info)
 static CORE_ADDR
 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;
+  struct solib_svr4_r_map_args args;
 
-  return read_memory_typed_address (info->debug_base + lmo->r_map_offset,
-				    ptr_type);
+  args.info = info;
+
+  /* Return 0 as a failure result if there is a memory read error.  */
+  args.retval = 0;
+
+  catch_exceptions (uiout, solib_svr4_r_map_stub, &args, RETURN_MASK_ERROR);
+
+  return args.retval;
 }
 
 /* Find r_brk from the inferior's debug base.  */