[RFC/PATCH] Extend gdb_core_cmd to allow "Cannot access memory..." messages

[Pedro Alves]

On 03/25/2015 12:06 AM, Sergio Durigan Junior wrote:> Hi,
>
> While hacking the coredump_filter patch, I noticed that, when you load a
> corefile on GDB and receive a "Cannot access memory at address..."
> message, gdb_core_cmd will fail and return -1, which means that some
> fatal error happened.
>
> Unfortunately, this kind of message does not mean that the user cannot
> continue debugging with the corefile; it meant that some memory region
> (sometimes not important) was inaccessible.  Given that
> gcore_create_callback, nowadays, will dump memory regions if they don't
> have the 'read' permission set (but have any other permission set), this
> kind of error can be expected sometimes.

So, gdb itself errors and stops processing the core?

>
> I would like to propose this patch to be applied, which will allow the
> test to continue even if this message is triggered.  I was not sure
> wether I should use a "pass" or "xfail" there, so I chose the second
> (which makes more sense to me).
>

Seems like you chose the first, not second.

> WDYT?

I think I don't understand.  :-)  Can you please show an
example session?  Did GDB continue processing the core when
it printed that error, or was it just a warning and it continued?

>From your message and patch, I assume the former, otherwise

 "Core was generated by .*\r\n$gdb_prompt $"

would still match, right?  If it didn't match, why not?

Your arguing that error "does not mean that the user cannot
continue debugging with the corefile".  So why paper over
this in the testsuite?  Saying "pass" in the testsuite when
it was "error" for gdb seems like a conflict.  It seems like what
we really should be discussing is whether that should be a
fatal error for the "core" command.

But as said, we'll need to see a gdb log and understand better
what gdb is doing to discuss this further.

Thanks,
Pedro Alves