From: Andrew Bennett <Andrew.Bennett@imgtec.com>
To: Mike Frysinger <vapier@gentoo.org>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: [PATCH] Add micromips support to the MIPS simulator
Date: Fri, 25 Sep 2015 12:06:00 -0000 [thread overview]
Message-ID: <0DA23CC379F5F945ACB41CF394B9827721126A60@LEMAIL01.le.imgtec.org> (raw)
In-Reply-To: <20150917044236.GB6834@vapier.lan>
> > No, they are required for some of the macros used in the file so they need
> to
> > stay in.
>
> this needs to be documented as to why. other ports don't need this, and
> it sounds like something wrong with the mips port that should be fixed at
> some point.
The definitions come from the *_support.h files generated by igen and are required
because they are used in some of the macros in the micromipsrun.c file.
Unfortunately we can not just blindly include the *_support.h files to get these
definitions because some of the defines in these files are specific for a particular
configuration of the simulator for example instruction word size is 16 bits for
micromips16 and 32 bits for micromips32. This means we could break future code
changes by doing this, so a safer approach is to just extract the defines that
we need to get the file to compile.
I have added a comment above the defines which explains this. The diff from my
previous patch is below.
Ok to commit?
Many thanks,
Andrew
diff --git a/sim/mips/micromipsrun.c b/sim/mips/micromipsrun.c
index 7dd10d7..c39138b 100644
--- a/sim/mips/micromipsrun.c
+++ b/sim/mips/micromipsrun.c
@@ -26,6 +26,14 @@
#include "bfd.h"
#include "sim-engine.h"
+/* These definitions come from the *_support.h files generated by igen and are
+ required because they are used in some of the macros in the code below.
+ Unfortunately we can not just blindly include the *_support.h files to get
+ these definitions because some of the defines in these files are specific
+ for a particular configuration of the simulator for example instruction word
+ size is 16 bits for micromips16 and 32 bits for micromips32. This means we
+ could break future code changes by doing this, so a safer approach is to just
+ extract the defines that we need to get this file to compile. */
#define SD sd
#define CPU cpu
next prev parent reply other threads:[~2015-09-25 12:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-21 12:44 Andrew Bennett
2015-02-24 5:44 ` Mike Frysinger
2015-08-27 15:05 ` Andrew Bennett
2015-09-11 10:24 ` Andrew Bennett
2016-01-01 7:07 ` Joel Brobecker
2016-01-05 14:40 ` Andrew Bennett
2016-01-06 5:43 ` Joel Brobecker
2015-09-17 4:42 ` Mike Frysinger
2015-09-25 12:06 ` Andrew Bennett [this message]
2015-09-25 14:07 ` Mike Frysinger
2015-09-25 20:22 ` Andrew Bennett
2015-09-25 20:57 ` Mike Frysinger
2016-01-12 23:01 ` Maciej W. Rozycki
2016-01-15 16:22 ` Andrew Bennett
2016-01-15 17:45 ` Mike Frysinger
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=0DA23CC379F5F945ACB41CF394B9827721126A60@LEMAIL01.le.imgtec.org \
--to=andrew.bennett@imgtec.com \
--cc=gdb-patches@sourceware.org \
--cc=vapier@gentoo.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