From: Pedro Alves <palves@redhat.com>
To: lgustavo@codesourcery.com
Cc: Yao Qi <yao@codesourcery.com>,
"'gdb-patches@sourceware.org'"
<gdb-patches@sourceware.org>,
Mike Frysinger <vapier@gentoo.org>
Subject: Re: [PATCH, gdbserver] Further cleanup of FDPIC/DSBT divergences
Date: Fri, 09 Aug 2013 15:08:00 -0000 [thread overview]
Message-ID: <520505D9.8080103@redhat.com> (raw)
In-Reply-To: <5203CA36.5000206@codesourcery.com>
On 08/08/2013 05:41 PM, Luis Machado wrote:
> Here is an updated patch that deals with solib-dsbt.c as well. The
> additional tic6x-specific fields from the loadmap were removed and
> dsbt_index is now fetched from the shared library file on disk instead
> of grabbing such information from the runtime loadmap. That information
> does not change anyway.
Is there no DT_DEBUG in auvx in FDPIC/DSBT we could consult first?
>
> +/* Scan for DYNTAG in .dynamic section of ABFD. If DYNTAG is found 1
Double space after period.
> + is returned and the corresponding PTR is set. We only search in
> + the BFD, not in the target's memory. */
> +
> +static int
> +scan_dyntag_in_bfd (int dyntag, bfd *abfd, CORE_ADDR *ptr)
> +{
> + int step, sect_size;
> + long dyn_tag;
> + CORE_ADDR dyn_ptr, dyn_addr;
> + gdb_byte *bufend, *bufstart, *buf;
> + Elf64_External_Dyn *x_dynp_64;
> + struct bfd_section *sect;
> + struct target_section *target_section;
> +
> + if (abfd == NULL)
> + return 0;
> +
> + if (bfd_get_flavour (abfd) != bfd_target_elf_flavour)
> + return 0;
> +
> + /* Make sure the size is sane. */
> + if (bfd_get_arch_size (abfd) == -1)
> + return 0;
> +
> + /* Find the start address of the .dynamic section. */
> + sect = bfd_get_section_by_name (abfd, ".dynamic");
> + if (sect == NULL)
> + return 0;
> +
> + for (target_section = current_target_sections->sections;
> + target_section < current_target_sections->sections_end;
> + target_section++)
> + if (sect == target_section->the_bfd_section)
> + break;
> + if (target_section < current_target_sections->sections_end)
> + dyn_addr = target_section->addr;
> + else
> + {
> + /* ABFD may come from OBJFILE acting only as a symbol file
> + without being loaded into the target
> + (see add_symbol_file_command). This case is such fallback
> + to the file VMA address without the possibility of having
> + the section relocated to its actual in-memory address. */
> +
> + dyn_addr = bfd_section_vma (abfd, sect);
> + }
> +
> + /* Read in .dynamic from the BFD. */
> + sect_size = bfd_section_size (abfd, sect);
> + buf = bufstart = alloca (sect_size);
> + if (!bfd_get_section_contents (abfd, sect,
> + buf, 0, sect_size))
> + return 0;
> +
> + /* Iterate over BUF and scan for DYNTAG. If found, set PTR and
> + return. */
> + step = sizeof (Elf64_External_Dyn);
> +
> + for (bufend = buf + sect_size;
> + buf < bufend;
> + buf += step)
> + {
> + x_dynp_64 = (Elf64_External_Dyn *) buf;
> + dyn_tag = bfd_h_get_64 (abfd, (bfd_byte *) x_dynp_64->d_tag);
> + dyn_ptr = bfd_h_get_64 (abfd, (bfd_byte *) x_dynp_64->d_un.d_ptr);
> +
> + if (dyn_tag == DT_NULL)
> + return 0;
> + if (dyn_tag == dyntag)
> + {
> + if (ptr)
if (ptr != NULL)
> + {
> + /* We don't want to read this information from memory.
> + If a relocation is needed, it should be done
> + elsewhere. */
> + *ptr = dyn_ptr;
> + }
> + return 1;
> + }
> + }
> +
> + return 0;
> +}
> +
Would solib-svr4.c's scan_dyntag work pristine here?
This duplication is making me like Maciej's idea of a
shared-between-elf-ish-solib-backends solib-elf.c file more.
> +/* Given a shared library filename, load it up and find
> + out what is its dsbt index. */
> +
> +static int
> +fetch_solib_dsbt_index (char *filename)
could be const?
> + target_read_string (addr, &name_buf, SO_NAME_MAX_PATH_SIZE - 1,
> + &errcode);
> +
> + if (errcode != 0)
> + dsbt_index = 0;
Is this an error path? Should it still have the warning removed below?
> + else
> {
> - warning (_("dsbt_current_sos: Unable to read dsbt index."
> - " Shared object chain may be incomplete."));
> - break;
> + /* Fetch the DSBT index of this load module. */
> + dsbt_index = fetch_solib_dsbt_index (name_buf);
> }
> - dsbt_index = extract_unsigned_integer (indexword, sizeof indexword,
> - byte_order);
>
the bit where that above was moved from:
> sop->lm_info->map = loadmap;
> - /* Fetch the name. */
> - addr = extract_unsigned_integer (lm_buf.l_name,
> - sizeof (lm_buf.l_name),
> - byte_order);
> - target_read_string (addr, &name_buf, SO_NAME_MAX_PATH_SIZE - 1,
> - &errcode);
>
> if (errcode != 0)
> warning (_("Can't read pathname for link map entry: %s."),
had the warning, but it isn't reachable, due to
if (dsbt_index != 0)
above.
Otherwise this is fine with me, if fine with Yao.
--
Pedro Alves
next prev parent reply other threads:[~2013-08-09 15:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-20 18:57 Luis Machado
2013-06-24 13:47 ` Yao Qi
2013-06-24 14:25 ` Luis Machado
2013-08-08 16:41 ` Luis Machado
2013-08-09 15:08 ` Pedro Alves [this message]
2013-08-09 17:20 ` Luis Machado
2013-08-10 0:33 ` Yao Qi
2013-08-12 13:41 ` Luis Machado
2013-08-12 14:06 ` Pedro Alves
2013-08-26 5:31 ` Mike Frysinger
2013-06-24 16:17 ` Mike Frysinger
2013-06-25 15:03 ` Pedro Alves
2013-06-25 15:04 ` Luis Machado
2013-06-25 16:26 ` Mike Frysinger
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=520505D9.8080103@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=lgustavo@codesourcery.com \
--cc=vapier@gentoo.org \
--cc=yao@codesourcery.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