Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Jim Blandy" <jimb@red-bean.com>
To: "Maciej W. Rozycki" <macro@mips.com>
Cc: "Daniel Jacobowitz" <drow@false.org>,
	gdb-patches@sourceware.org,
	 	"Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: MIPS: Handle manual calls of MIPS16 functions with a call stub
Date: Wed, 13 Feb 2008 20:54:00 -0000	[thread overview]
Message-ID: <8f2776cb0802131254p7fd04ba5lf908414940b7f622@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0802131810250.19972@perivale.mips.com>

On Feb 13, 2008 10:27 AM, Maciej W. Rozycki <macro@mips.com> wrote:
> On Fri, 8 Feb 2008, Jim Blandy wrote:
> > Putting ISA information in low bits of DWARF attribute values isn't
> > the way we've decided to do things.
>
>  Unfortunately this is what the current versions of the relevant tools do
> and I think it has been like this for a while.  The linker does not
> differentiate between relocations used for taking an address of a function
> for the purpose of making a call and for other uses and the same
> relocation types are used in both cases.
>
>  Ultimately it is the linker that should be fixed (though from the current
> behaviour I think GAS has a problem here as well), but I am afraid broken
> tools and broken binaries are going to be out there for a while yet, so it
> may be a reasonable idea to try to handle them as well as possible.  I
> recognise pointer_to_address() may not be the best choice here though.
>
>  However I think it will have to be involved anyway elsewhere as I find
> the current model assumed by GDB inconsistent.

It seems that we all agree on the following:

- It's contrary to the DWARF spec for producers to put arch-specific
  information in the low bits of the addresses in the line number
  table, function and block address ranges, and so on.  Existing
  toolchains that do this are buggy, but that's life.

- The addresses in GDB's line tables and block ranges should not have
  such extra bits set in them.

- The proper place to store arch-specific data on minimal symbols is
  in the 'info' field of 'struct minimal_symbol'.  In cases like
  MIPS16, the gdbarch_push_dummy_call method can consult that
  information at call time to see which calling convention is
  appropriate.

If we agree that we want to work around the linker bugs in GDB's
reader, that means we have to clear those bits and stash the
information elsewhere when we read the DWARF.  So something like
Maciej's original patch doesn't seem wrong to me.

The name 'make_symbol_special' seems awfully vague, though.  Is the
term 'special' inherited from outside GDB, or did it originate within
GDB?  In either case, I don't want it propagating into the DWARF
reader; that's horrible.  :)


  reply	other threads:[~2008-02-13 20:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-31 18:14 Maciej W. Rozycki
2008-01-31 22:08 ` Daniel Jacobowitz
2008-02-01 10:27   ` Maciej W. Rozycki
2008-02-01 14:19     ` Daniel Jacobowitz
2008-02-01 15:34       ` Maciej W. Rozycki
2008-02-01 16:58         ` Daniel Jacobowitz
2008-02-01 17:07           ` Maciej W. Rozycki
2008-02-01 17:15             ` Daniel Jacobowitz
2008-02-04 16:14     ` Maciej W. Rozycki
2008-02-04 16:39       ` Daniel Jacobowitz
2008-02-08 14:23         ` Maciej W. Rozycki
2008-02-08 14:57           ` Daniel Jacobowitz
2008-02-08 18:06           ` Jim Blandy
2008-02-08 18:08           ` Jim Blandy
2008-02-13 18:28             ` Maciej W. Rozycki
2008-02-13 20:54               ` Jim Blandy [this message]
2008-02-15 11:36                 ` Maciej W. Rozycki
2008-02-18 13:32                   ` Nigel Stephens
2008-02-18 16:28                     ` Maciej W. Rozycki
2008-02-19 19:48                       ` Michael Snyder
2008-02-22 16:38                     ` Jim Blandy

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=8f2776cb0802131254p7fd04ba5lf908414940b7f622@mail.gmail.com \
    --to=jimb@red-bean.com \
    --cc=drow@false.org \
    --cc=gdb-patches@sourceware.org \
    --cc=macro@linux-mips.org \
    --cc=macro@mips.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