From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
To: gdb-patches@sourceware.org
Subject: Re: [RFC][PATCH] Move common handlers to sol2_init_abi
Date: Wed, 24 Jun 2020 12:27:38 +0200 [thread overview]
Message-ID: <yddmu4soj1h.fsf@CeBiTec.Uni-Bielefeld.DE> (raw)
In-Reply-To: <yddr1u5orci.fsf@CeBiTec.Uni-Bielefeld.DE> (Rainer Orth's message of "Tue, 23 Jun 2020 15:15:57 +0200")
Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:
> There's some overlap and duplication between 32 and 64-bit Solaris/SPARC
> and x86 tdep files, in particular
>
> sol2_core_pid_to_str
> *_sol2_sigtramp_p
> sol2_skip_solib_resolver
> *_sol2_static_transform_name (forgotten on amd64)
> set_gdbarch_sofun_address_maybe_missing (likewise)
>
> This patch avoids this by centralizing common code in sol2-tdep.c.
> While sparc_sol2_pc_in_sigtramp and sparc_sol2_static_transform_name
> were declared in the shared sparc-tdep.h, they were only used in Solaris
> files.
>
> However, I just discovered that there are two targets that would break
> with this patch: both sparc-*-linux* and sparc64-*-linux* include
> sparc-sol2-tdep.o and sparc64-sol2-tdep.o in configure.tgt. With the
> new call to sol2_init_abi which only lives in sol2-tdep.o, gdb would
> fail to link. I have no idea what business they have with
> Solaris-specific files: I suspect that's to allow debugging of
> Solaris/SPARC binaries (i.e. GDB_OSABI_SOLARIS). What should I do about
> this? Maybe I also could include sol2-tdep.o on Linux/SPARC, but is
> this TRT? AFAICS those files received only mechanical changes over the
> last two years (haven't looked further), and I have no way of testing
> changes.
I must have been half asleep when I wrote this: sparc*-*-linux* already
*does* link sol2-tdep.o. I've now verified (on gcc202 in the GCC
compile farm) that gdb links without and with my patch, so I'm going to
install the patch soon.
I couldn't do a proper regtest, however, since even unmodified master
ran into a tight loop testing gdb.base/testenv.exp (it went up to 4.4+
million iterations before I noticed the problem). I cannot report the
details now since the system has been unaccessible for two days.
The other questions raised in the patch submission still hold, though.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
next prev parent reply other threads:[~2020-06-24 10:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-23 13:15 Rainer Orth
2020-06-24 10:27 ` Rainer Orth [this message]
2020-06-24 14:56 ` Simon Marchi
2020-06-24 20:57 ` Rainer Orth
2020-06-25 8:23 ` [PATCH] Don't include *sol2-tdep.o on Linux/sparc* Rainer Orth
2020-06-25 9:57 ` Pedro Alves
2020-06-25 12:03 ` Rainer Orth
2020-06-25 8:26 ` [PATCH] Remove obsolete gdbarch_static_transform_name Rainer Orth
2020-06-25 9:18 ` Pedro Alves
2020-06-25 12:07 ` Rainer Orth
2020-06-25 15:20 ` Pedro Alves
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=yddmu4soj1h.fsf@CeBiTec.Uni-Bielefeld.DE \
--to=ro@cebitec.uni-bielefeld.de \
--cc=gdb-patches@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).