From: "Maciej W. Rozycki" <macro@mips.com>
To: Jim Blandy <jimb@red-bean.com>
Cc: Daniel Jacobowitz <drow@false.org>,
Nigel Stephens <nigel@mips.com>,
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: Fri, 15 Feb 2008 11:36:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.61.0802151113430.26997@perivale.mips.com> (raw)
In-Reply-To: <8f2776cb0802131254p7fd04ba5lf908414940b7f622@mail.gmail.com>
On Wed, 13 Feb 2008, Jim Blandy wrote:
> 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.
I certainly agree here.
> 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.
OK, but the original patch does not clear the bit, but actually it sets
it in the single case discovered so far where GAS gets it wrong (and
linker does not fix up in any way). What I attempted meanwhile was to
adjust the DWARF reader so that it effectively ignores the bit. It proved
not as straightforward as it could immediately be thought it would be as
with some structures addresses are calculated cumulatively and one or more
addends may be odd. It is therefore necessary, where applicable, not only
to mask out the LSB, but also to remember its value and carry it forward
to the next addition.
What I have developed is a crude hack as a proof of concept which just
does all the extra calculation unconditionally so that I could verify it
was at all workable as well as identify all the places that would have to
be changed and how. If there is agreement to push this approach forward I
will have a look at how to do this properly.
> 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. :)
I have just derived an arbitrary name from make_msymbol_special. No
preference either way, but I gather this is not the way we want to go
anyway.
Maciej
next prev parent reply other threads:[~2008-02-15 11:36 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
2008-02-15 11:36 ` Maciej W. Rozycki [this message]
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=Pine.LNX.4.61.0802151113430.26997@perivale.mips.com \
--to=macro@mips.com \
--cc=drow@false.org \
--cc=gdb-patches@sourceware.org \
--cc=jimb@red-bean.com \
--cc=macro@linux-mips.org \
--cc=nigel@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