From: Iain Buclaw <ibuclaw@gdcproject.org>
To: Joseph Myers <joseph@codesourcery.com>,
Richard Biener <richard.guenther@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported (PR105659)
Date: Wed, 31 Aug 2022 14:10:47 +0200 [thread overview]
Message-ID: <1661946124.o8swlumpp1.astroid@pulse.none> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2208302151520.446383@digraph.polyomino.org.uk>
Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
> On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
>
>> I was hoping Joseph would chime in here - I recollect debugging this kind
>> of thing and a thread about this a while back but unfortunately I do not
>> remember the details here (IIRC some things get included where they
>> better should not be).
>
> See <https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582563.html>.
> Is there some reason it's problematic to avoid having defaults.h or
> ${cpu_type}/${cpu_type}.h included in tm_d.h, and instead have tm_d.h only
> include D-specific headers?
>
In targets such as arm-elf, we still need to pull in definitions from
${cpu_type}/${cpu_type}-d.cc into default-d.cc.
All I can think that might suffice is having D-specific prototype
headers in all targets as ${cpu_type}/${cpu_type}-d.h.
At this location:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config.gcc;h=1104508488818ff589dbc0890cf3fc475ae5977a;hb=refs/heads/master#l560
if test -f ${srcdir}/config/${cpu_type}/${cpu_type}-d.h
then
tm_d_file=${cpu_type}/${cpu_type}-d.h
fi
Looks like RustFE ripped out their target support for now.
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=1c8ebf66965509008329b6e0425ffda407265263
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=3cd9342634e38100a9fa6a4bec4d958ca3a4ab60
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=a15ee6c3e5d710556d145e6af499b09993c4ee64
Iain.
next prev parent reply other threads:[~2022-08-31 12:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-16 21:16 Iain Buclaw
2022-08-26 8:42 ` Richard Biener
2022-08-30 21:53 ` Joseph Myers
2022-08-31 12:10 ` Iain Buclaw [this message]
2022-08-31 17:16 ` Joseph Myers
2022-08-31 19:21 ` Iain Buclaw
2022-09-01 6:28 ` Richard Biener
2022-09-02 16:05 ` Iain Buclaw
2022-09-06 7:42 ` Rainer Orth
2022-09-06 10:51 ` Iain Buclaw
2022-09-06 12:04 ` Rainer Orth
2022-09-06 14:19 ` Iain Buclaw
2022-09-06 14:25 ` Rainer Orth
2022-09-06 17:02 ` Iain Buclaw
2022-09-06 21:41 ` Iain Buclaw
2022-09-07 7:34 ` Iain Buclaw
2022-09-07 12:40 ` Rainer Orth
2022-09-07 13:11 ` Iain Buclaw
2022-09-07 13:21 ` Rainer Orth
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=1661946124.o8swlumpp1.astroid@pulse.none \
--to=ibuclaw@gdcproject.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=joseph@codesourcery.com \
--cc=richard.guenther@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).