Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Nick Duffek <nsd@redhat.com>
To: kevinb@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] osfsolib.c: support Tru64 5.x
Date: Thu, 24 May 2001 18:58:00 -0000	[thread overview]
Message-ID: <200105250208.f4P28bh07022@rtl.cygnus.com> (raw)
In-Reply-To: <1010516000146.ZM9797@ocotillo.lan>

On 15-May-2001, Kevin Buettner wrote:

>On May 14,  9:44pm, Nick Duffek wrote:
[...]
>> Index: gdb/solist.h
[...]
>> +       current_sos must initialize these fields to 0.  */

>Good catch.  Please check this in.

Checked in.

>> 2. Because Tru64 doesn't use ELF binaries, "info sharedlibrary"
>> incorrectly infers the address size to be 32 bits
[...]
>> Some possible fixes:
>>   (a) Default to 64 instead of 32 bits.
>>   (b) Use something like bfd_arch_bits_per_address(exec_bfd) instead of
>>       or in addition to bfd_get_arch_size (exec_bfd).
>
>Option (b) sounds better to me.

The appended patch does that.

I ran into another problem: section name addresses in Tru64 shared module
lists refer to areas in /sbin/loader, which is the first element in the
shared module list.  Consequently, when the relocate_section_addresses()
callback tries to match BFD section names with those from the shared
module list, it can't read the latter.  (Actually, it can when debugging a
live process, because /sbin/loader is part of the address space viewable
from procfs, but not when debugging a core file.)

A solution is to reorganize update_solib_list() in solib.c to do this:

  for (each module) {
    call target_so_ops.relocate_section_addresses();
    add sections to lookup table using target_resize_to_sections();
  }

instead of this:

  for (each module) {
    call target_so_ops.relocate_section_addresses();
  }
  for (each module) {
    add sections to lookup table using target_resize_to_sections();
  }

That way, each relocate_section_addresses() callback can read addresses
from all objects earlier in the module list.

The appended patch makes that change as well.  With the patch and with the
new solib-osf.c backend that I'll post shortly, there are no regressions
(and several progressions) on Tru64 5.0 and Digital UNIX 4.0.

Okay to apply?

Nick

2001-05-24  Nick Duffek  <nsd@redhat.com>

	* solib.c (update_solib_list): Move target_resize_to_sections()
	into solib_map_sections() loop.
	(info_sharedlibrary_command): Try bfd_arch_bits_per_address() if
	bfd_get_arch_size() fails.

Index: gdb/solib.c
===================================================================
diff -up gdb/solib.c gdb/solib.c
--- gdb/solib.c	Thu May 24 21:22:28 2001
+++ gdb/solib.c	Thu May 24 21:22:12 2001
@@ -461,30 +461,20 @@ update_solib_list (int from_tty, struct 
 	  catch_errors (solib_map_sections, i,
 			"Error while mapping shared library sections:\n",
 			RETURN_MASK_ALL);
-	}
-
-      /* If requested, add the shared objects' sections to the the
-	 TARGET's section table.  */
-      if (target)
-	{
-	  int new_sections;
 
-	  /* Figure out how many sections we'll need to add in total.  */
-	  new_sections = 0;
-	  for (i = inferior; i; i = i->next)
-	    new_sections += (i->sections_end - i->sections);
-
-	  if (new_sections > 0)
+	  /* If requested, add the shared object's sections to the TARGET's
+	     section table.  Do this immediately after mapping the object so
+	     that later noes in the list can query this object, as is needed
+	     in solib-osf.c.  */
+	  if (target)
 	    {
-	      int space = target_resize_to_sections (target, new_sections);
-
-	      for (i = inferior; i; i = i->next)
+	      int count = (i->sections_end - i->sections);
+	      if (count > 0)
 		{
-		  int count = (i->sections_end - i->sections);
+		  int space = target_resize_to_sections (target, count);
 		  memcpy (target->to_sections + space,
 			  i->sections,
 			  count * sizeof (i->sections[0]));
-		  space += count;
 		}
 	    }
 	}
@@ -605,7 +595,10 @@ info_sharedlibrary_command (char *ignore
     }
 
   arch_size = bfd_get_arch_size (exec_bfd);
-  /* Default to 32-bit in case of failure (non-elf). */
+  if (arch_size == -1)
+    arch_size = bfd_arch_bits_per_address(exec_bfd);
+
+  /* Default to 32-bit in case of failure.  */
   if (arch_size == 32 || arch_size == -1)
     {
       addr_width = 8 + 4;


  reply	other threads:[~2001-05-24 18:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-12 16:45 Nicholas Duffek
2001-05-13  0:06 ` Kevin Buettner
2001-05-14 18:34   ` Nick Duffek
2001-05-15 17:02     ` Kevin Buettner
2001-05-24 18:58       ` Nick Duffek [this message]
     [not found] <1010525224132.ZM16493@ocotillo.lan>
2001-05-25 17:37 ` Nick Duffek
2001-05-25 18:08   ` Kevin Buettner
2001-05-25 17:55 ` Nick Duffek

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=200105250208.f4P28bh07022@rtl.cygnus.com \
    --to=nsd@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kevinb@cygnus.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