public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "dje at google dot com" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug symtab/17199] New: Recording two copies of plt minimal symbols is a pain to deal with
Date: Fri, 25 Jul 2014 16:58:00 -0000	[thread overview]
Message-ID: <bug-17199-4717@http.sourceware.org/bugzilla/> (raw)

https://sourceware.org/bugzilla/show_bug.cgi?id=17199

            Bug ID: 17199
           Summary: Recording two copies of plt minimal symbols is a pain
                    to deal with
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: minor
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: dje at google dot com

If there's a category for code cleanup issues, this goes there.

Creating two copies of plt minimal symbols is a pain to deal with.
It complicates trying to understand what's going on, not least of which
because foo@plt gets mst_text and foo gets mst_solib_trampoline ("foo" is the
"special" symbol here, not foo@plt).

I understand the problem being solved here, I'm just thinking there's
got to be a cleaner way.

elfread.c:

          /* For @plt symbols, also record a trampoline to the                  
             destination symbol.  The @plt symbol will be used in               
             disassembly, and the trampoline will be used when we are           
             trying to find the target.  */
          if (msym && ms_type == mst_text && type == ST_SYNTHETIC)
            {
              int len = strlen (sym->name);

              if (len > 4 && strcmp (sym->name + len - 4, "@plt") == 0)
                {
                  struct minimal_symbol *mtramp;

                  mtramp = record_minimal_symbol (sym->name, len - 4, 1,
                                                  symaddr,
                                                  mst_solib_trampoline,
                                                  sym->section, objfile);
                  if (mtramp)
                    {
                      SET_MSYMBOL_SIZE (mtramp, MSYMBOL_SIZE (msym));
                      mtramp->created_by_gdb = 1;
                      mtramp->filename = filesymname;
                      gdbarch_elf_make_msymbol_special (gdbarch, sym, mtramp);
                    }
                }
            }

-- 
You are receiving this mail because:
You are on the CC list for the bug.


             reply	other threads:[~2014-07-25 16:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-25 16:58 dje at google dot com [this message]
2014-07-25 19:42 ` [Bug symtab/17199] " dje at google dot com
2014-07-26 21:48 ` xdje42 at gmail dot com
2023-02-12  6:21 ` cvs-commit at gcc dot gnu.org

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=bug-17199-4717@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).