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: [patch] Fix a crash when displaying variables from shared library.


On Mon, Mar 9, 2009 at 11:33 AM, Joel Brobecker <brobecker@adacore.com> wrote:

>> 2009-03-06  Paul Pluzhnikov  <ppluzhnikov@google.com>
>>
>>           * solib.c (solib_contains_address_p): New function.
>
> Looks great to me. Go ahead and check it in.

Thanks, so committed.

And now we come back to the shlib_disable question.

With the change above, I believe it to be quite reasonable to update
breakpoint.c as attached patch does.

But doing that breaks attach.exp again:
  FAIL: gdb.base/attach.exp: attach1 detach
due to:
  warning: Temporarily disabling breakpoints for unloaded shared
library "/lib64/ld-linux-x86-64.so.2"

With current code we don't issue the warning, but only because
ld-linux has already been removed from the so_list_head, and so
solib_name_from_address() returns NULL.

It looks to me that this works purely by accident, and so I ask
again: shouldn't all types of breakpoints, and not just
bp_breakpoint and bp_hardware_breakpoint, be shlib_disabled in
disable_breakpoints_in_shlibs?

I went ahead and did this:

diff -u -p -u -r1.382 breakpoint.c
--- breakpoint.c        6 Mar 2009 18:51:05 -0000       1.382
+++ breakpoint.c        9 Mar 2009 22:55:02 -0000
@@ -4434,8 +4434,7 @@ disable_breakpoints_in_shlibs (void)
        becomes enabled, or the duplicate is removed, gdb will try to insert
        all breakpoints.  If we don't set shlib_disabled here, we'll try
        to insert those breakpoints and fail.  */
-    if (((b->type == bp_breakpoint) || (b->type == bp_hardware_breakpoint))
-       && !loc->shlib_disabled
+    if (!loc->shlib_disabled
 #ifdef PC_SOLIB
        && PC_SOLIB (loc->address)
 #else

And that did not produce any new failures on Linux/x86_64.

It appears to me that this is the logically correct thing to do.

Thanks,
-- 
Paul Pluzhnikov

Attachment: gdb-display-crash-20090309.txt
Description: Text document


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