Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Vladimir Prus <vladimir@codesourcery.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] Handle solaris dynamic linker name change.
Date: Mon, 07 Jan 2008 15:24:00 -0000	[thread overview]
Message-ID: <200801071823.57195.vladimir@codesourcery.com> (raw)
In-Reply-To: <20080104153020.GB5975@adacore.com>

[-- Attachment #1: Type: text/plain, Size: 2928 bytes --]

On Friday 04 January 2008 18:30:20 Joel Brobecker wrote:
> > > I'd like the feedback from other maintainers about this.
> > 
> > I think it's fine with that improvement or without it; I really doubt
> > the code will trigger anywhere else.  My two cents.
> 
> OK, in that case, let's leave it the way Volodya original proposed it.
> I'd just like us to add a comment in svr4_same to say that we don't
> restrict the check to solaris, but that the chances of facing this
> situation in any other OS are very small.
> 
> Looking again at the patch:
> 
> > 	Ignore change in name of dynamic linker during
> > 	execution.  This also unbreaks pending breakpoints.
> > 	* solist.h (struct target_so_ops): New field
> > 	same.
> > 	* solib-svr4.c (svr4_same): New.
> > 	(_initialize_svr4_solib): Register svr4_same.
> > 	* solib.c (update_solib_list): Use ops->same,
> > 	if available.
> 
> Just a very very minor comment: Your fill-column looks very small, and
> makes it harder to read your sentences. It's supposed to be 74. Don't
> go out of your way to fix, though, in the grand scheme of things,
> I don't think that you're breaking a GNU Coding standard rule (I just
> did a quick check of the section detailing ChangeLogs).
> 
> > +  /* On Solaris, when starting inferior we think that
> > +     dynamic linker is /usr/lib/ld.so.1, but later on,
> > +     the table of loaded shared libraries contains
> > +     /lib/ld.so.1.
> > +     Sometimes one file is a link to another, but sometimes
> > +     they have identical content, but are not linked to each
> > +     other.  */
> 
> Same small fill-column ;-). Actually, the real comment is to remind
> you that an extra comment as explained at the beginning of this email
> would be appreciated.
> 
> > +  if (strcmp (gdb->so_original_name, "/usr/lib/ld.so.1") == 0
> > +      && strcmp (inferior->so_original_name, "/lib/ld.so.1") == 0)
> > +    return 1;
> 
> Is it always going to be in that order (original in /usr/lib and
> gdb in /usr)? Or was this from experience?

This is from experience. Since we don't know why Solaris behave this way,
we probably cannot guess if the other way round is possible, and how
to handle it.

> 
> > +    /* Given two so_list, first from GDB thread list and another
> > +       present in the list returned by current_sos, return 1 if
> > +       they are equal -- referring to the same library.  */
> > +    int (*same) (struct so_list *gdb, struct so_list *inferior);
> 
> I am not a native English speaker, but the above sounds funny.
> I suggest a slightly different version:
> 
> 
>     /* Given two so_list objects, one from the GDB thread list
>        and another from the list returned by current_sos, return 1
>        if they represent the same library.  */
> 
> This is all I have - your patch is pre-approved with the comment
> adjustments.  

Thanks. I've adjusted comments as shown in attachment and checked in.

- Volodya

[-- Attachment #2: delta.diff --]
[-- Type: text/x-diff, Size: 1861 bytes --]

diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
index 32912ea..4c9e82d 100644
--- a/gdb/solib-svr4.c
+++ b/gdb/solib-svr4.c
@@ -1575,13 +1575,12 @@ svr4_same (struct so_list *gdb, struct so_list *inferior)
   if (! strcmp (gdb->so_original_name, inferior->so_original_name))
     return 1;
 
-  /* On Solaris, when starting inferior we think that
-     dynamic linker is /usr/lib/ld.so.1, but later on,
-     the table of loaded shared libraries contains
-     /lib/ld.so.1.
-     Sometimes one file is a link to another, but sometimes
-     they have identical content, but are not linked to each
-     other.  */
+  /* On Solaris, when starting inferior we think that dynamic linker is
+     /usr/lib/ld.so.1, but later on, the table of loaded shared libraries 
+     contains /lib/ld.so.1.  Sometimes one file is a link to another, but 
+     sometimes they have identical content, but are not linked to each
+     other.  We don't restrict this check for Solaris, but the chances
+     of running into this situation elsewhere are very low.  */
   if (strcmp (gdb->so_original_name, "/usr/lib/ld.so.1") == 0
       && strcmp (inferior->so_original_name, "/lib/ld.so.1") == 0)
     return 1;
diff --git a/gdb/solist.h b/gdb/solist.h
index 915b137..01f734f 100644
--- a/gdb/solist.h
+++ b/gdb/solist.h
@@ -115,9 +115,9 @@ struct target_so_ops
 						 const domain_enum domain,
 						 struct symtab **symtab);
 
-    /* Given two so_list, first from GDB thread list and another
-       present in the list returned by current_sos, return 1 if
-       they are equal -- referring to the same library.  */
+    /* Given two so_list objects, one from the GDB thread list
+       and another from the list returned by current_sos, return 1
+       if they represent the same library.  */
     int (*same) (struct so_list *gdb, struct so_list *inferior);
   };
 

      reply	other threads:[~2008-01-07 15:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-26  6:00 Vladimir Prus
2007-12-27 18:18 ` Doug Evans
2007-12-27 18:37   ` Vladimir Prus
2008-01-04  5:50 ` Joel Brobecker
2008-01-04 12:46   ` Daniel Jacobowitz
2008-01-04 15:30     ` Joel Brobecker
2008-01-07 15:24       ` Vladimir Prus [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200801071823.57195.vladimir@codesourcery.com \
    --to=vladimir@codesourcery.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox