public inbox for gdb-cvs@sourceware.org
help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@sourceware.org>
To: gdb-cvs@sourceware.org
Subject: [binutils-gdb] sim/erc32: fix gdb with simulator build
Date: Sun,  4 Sep 2022 17:03:05 +0000 (GMT)	[thread overview]
Message-ID: <20220904170305.0595A3857B8D@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a411a714f31da81e6c57317f1d392e166053dff1

commit a411a714f31da81e6c57317f1d392e166053dff1
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Sun Sep 4 17:49:11 2022 +0100

    sim/erc32: fix gdb with simulator build
    
    In commit:
    
      commit 7b01c1cc1d111ba0afa51e60fa9842d3b971e2d1
      Date:   Mon Apr 4 22:38:04 2022 +0100
    
          sim: fixes for libopcodes styled disassembler
    
    changes were made to the simulator source to handle the new libopcodes
    disassembler styling API.
    
    Unfortunately, these changes broke building GDB with the erc32 (sparc)
    simulator, like this:
    
      ../src/configure --target=sparc-linux
      make all-gdb
      ....
      /usr/bin/ld: ../sim/erc32/libsim.a(interf.o): in function `sim_open':
      /tmp/build/sim/../../src/sim/erc32/interf.c:247: undefined reference to `fprintf_styled'
      collect2: error: ld returned 1 exit status
    
    The problem is that in commit 7b01c1cc1d11 the fprintf_styled function
    was added into sis.c.  This file is only used when building the 'run'
    binary, that is, the standalone simulator, and is not included in the
    libsim.a library.
    
    Now, the obvious fix would be to move fprintf_styled into libsim.a,
    however, that turns out to be tricky.
    
    The erc32 simulator currently has two copies of the function run_sim,
    one in sis.c, and one in interf.c, both of these copies are global.
    
    Currently, the 'run' binary links fine, though I suspect this might be
    pure luck.  When I tried moving fprintf_styled into interf.c, I ran
    into multiple-definition (of run_sim) errors.  I suspect that by
    requiring the linker to pull in fprintf_styled from libsim.a I was
    changing the order in which symbols were loaded, and the linker was
    now seeing both copies of run_sim, while currently we only see one
    copy.
    
    The ideal solution of course, would be to merge the two similar, but
    slightly different copies of run_sim, and just use the one copy.  Then
    we could safely move fprintf_styled into interf.c too, and all would
    be good.
    
    But I don't have time right now to start debugging the erc32
    simulator, so I wanted a solution that fixes the build without
    introducing multiple definition errors.
    
    The easiest solution I think is to just have two copies of
    fprintf_styled, one in sis.c, and one in interf.c.  Unlike run_sim,
    these two copies are both static, so we will not run into multiple
    definition issues with this function.  The functions themselves are
    not very big, so it's not a huge amount of duplicate code.
    
    I am very aware that this is not an ideal solution, and I would
    welcome anyone who wants to take on fixing the run_sim problem
    properly, and then cleanup the fprintf_styled duplication.

Diff:
---
 sim/erc32/interf.c | 15 +++++++++++++++
 sim/erc32/sis.c    |  2 +-
 sim/erc32/sis.h    |  2 --
 3 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/sim/erc32/interf.c b/sim/erc32/interf.c
index 78dec6f4b9b..f433b9d55ac 100644
--- a/sim/erc32/interf.c
+++ b/sim/erc32/interf.c
@@ -156,6 +156,21 @@ run_sim(struct pstate *sregs, uint64_t icount, int dis)
     return TIME_OUT;
 }
 
+static int
+fprintf_styled (void *stream, enum disassembler_style style,
+		const char *fmt, ...)
+{
+  int ret;
+  FILE *out = (FILE *) stream;
+  va_list args;
+
+  va_start (args, fmt);
+  ret = vfprintf (out, fmt, args);
+  va_end (args);
+
+  return ret;
+}
+
 SIM_DESC
 sim_open (SIM_OPEN_KIND kind, struct host_callback_struct *callback,
 	  struct bfd *abfd, char * const *argv)
diff --git a/sim/erc32/sis.c b/sim/erc32/sis.c
index 12eb21f15a7..1d3ea139c23 100644
--- a/sim/erc32/sis.c
+++ b/sim/erc32/sis.c
@@ -138,7 +138,7 @@ run_sim(struct pstate *sregs, uint64_t icount, int dis)
     return TIME_OUT;
 }
 
-int
+static int
 fprintf_styled (void *stream, enum disassembler_style style,
 		const char *fmt, ...)
 {
diff --git a/sim/erc32/sis.h b/sim/erc32/sis.h
index 3a276670402..71033137f2c 100644
--- a/sim/erc32/sis.h
+++ b/sim/erc32/sis.h
@@ -204,8 +204,6 @@ extern void	init_regs (struct pstate *sregs);
 /* interf.c */
 extern int	run_sim (struct pstate *sregs,
 			 uint64_t icount, int dis);
-extern int      fprintf_styled (void *stream, enum disassembler_style style,
-				const char *fmt, ...) ATTRIBUTE_PRINTF (3, 4);
 
 /* float.c */
 extern int	get_accex (void);

                 reply	other threads:[~2022-09-04 17:03 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20220904170305.0595A3857B8D@sourceware.org \
    --to=aburgess@sourceware.org \
    --cc=gdb-cvs@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).