[00/40] sim+gdb: Suppress warnings if built with Clang (big batch 1)

  Hi all,

In my environment (Ubuntu 22.04.1 LTS + LLVM Clang 15.0.0/15.0.3), I have
finally managed to build almost default configuration of all-arch Binutils +
GDB ("--enable-targets=all") with Clang and -Werror enabled (by default).

This patchset is what I originally intended to split to multiple parts (in
fact, I submitted several patchsets that are originally a part of this) but
shared here (without splitting) to discuss and share information who wants
to build Binutils + GDB with Clang.

Related components (for review):
-   3 : cpu (Binutils)
    -   PATCH 04/40 (CRIS)
    -   PATCH 05/40 (CRIS)
    -   PATCH 11/40 (FR-V)
-   1 : gdb (GDB)
    -   PATCH 01/40 (same patch as below):
        <https://sourceware.org/pipermail/gdb-patches/2022-October/192802.html>
-  36 : sim (GDB)

Each resolves relatively small issue and/or non-issue (which Clang thinks
it is a problem).


[Credit]

PATCH 16/40 is entirely authored by Andrew Burgess (exactly the same as):
<https://sourceware.org/pipermail/gdb-patches/2022-October/192841.html>


[Limitation]

I only tested this on Linux (x86_64) and with almost default configuration.
My initial submission of gdb patch above confirmed broken on Mac due to
different C++ standard library (fixed though) but I cannot guarantee whether
this patchset is all we need.
So, non-default components and non-default configurations may still have
problems building with Clang (e.g. assemblers except x86).


[Shared Technique: Explicit cast to CGEN_INSN_TYPE]

-   PATCH 07/40: CRIS (in the process of regenerating all files)
-   PATCH 14/40: FR-V
-   PATCH 17/40: LatticeMicro32
-   PATCH 23/40: M32R
-   PATCH 38/40: BPF
-   PATCH 39/40: IQ2000
-   PATCH 40/40: OpenRISC 1000

In CGEN-generated instruction decoder, instruction type has CGEN_INSN_TYPE
values but some contain CGEN_INSN_VIRTUAL_TYPE values.  On such cases,
CGEN_INSN_VIRTUAL_TYPE values must be explicitly converted to CGEN_INSN_TYPE
to prevent build failure caused by Clang warnings ("-Wenum-conversion").

I'm going to upstream this change to CGEN but due to known regressions,
I did not regenerate those files using CGEN (except CRIS (PATCH 07/40),
which I used a WIP version of CGEN).


[Related Patches]

-   PATCH 02/40 is a prerequisite of PATCH 26/40.
    We don't want to declare getrusage ourself (as possible).
    If we have a known declaration of getrusage with known prototype,
    we no longer need to declare getrusage with indeterminate arguments
    (without prototype).  This is similar to getopt in Binutils.


Thanks,
Tsukasa




Andrew Burgess (1):
  sim/lm32: fix some missing function declaration warnings

Tsukasa OI (39):
  gdb/unittests: PR28413, suppress warnings generated by Gnulib
  sim: Check known getrusage declaration existence
  sim/aarch64: Remove unused functions
  cpu/cris: Initialize some variables on CRIS CPU
  cpu/cris: Add u-stall virtual unit to CRIS v32
  sim/cris: Move declarations of f_specific_init
  sim/cris: Regenerate with CGEN
  sim/erc32: Insert void parameter
  sim/erc32: Use int32_t as event callback argument
  sim/erc32: Use int32_t as IRQ callback argument
  cpu/frv: Initialize some variables
  sim/frv: Initialize nesr variable
  sim/frv: Initialize some variables
  sim/frv: Add explicit casts
  sim/h8300: Add "+ 0x0" to avoid self-assignments
  sim/lm32: Add explicit casts
  sim/m32c: Stop using middle dot
  sim/m32r: Initialize "list" variable
  sim/m32r: Prepare required functions
  sim/m32r: Declare all required functions
  sim/m32r: Fixes to Linux emulator
  sim/m32r: Add explicit casts
  sim/mips: Fix enum type-related issues on cp1.c
  sim/mn10300: Add an explicit cast
  sim/ppc: Remove getrusage declarations if possible
  sim/ppc: Add extra parenthesis to avoid ambiguity
  sim/ppc: Initialize stat type buffer
  sim/ppc: Fix indentation on generated code
  sim/ppc: Use TRACE with initialized entry_point
  sim/ppc: Initialize help variables
  sim/ppc: Add an explicit cast
  sim/ppc: Initialize reg and control_nr
  sim/rx: Mark unused function
  sim/sh: Initialize some variables
  sim/sh: Use fabs instead of abs
  sim/sh: Remove redundant function declaration
  sim/bpf: Add explicit casts
  sim/iq2000: Add explicit casts
  sim/or1k: Add explicit casts

 cpu/cris.cpu                          |  4 ++++
 cpu/frv.cpu                           |  3 +++
 gdb/unittests/string_view-selftests.c |  7 ++++++
 sim/aarch64/simulator.c               | 16 --------------
 sim/bpf/decode-be.c                   | 14 ++++++------
 sim/bpf/decode-le.c                   | 14 ++++++------
 sim/config.h.in                       |  4 ++++
 sim/configure                         | 32 +++++++++++++++++++++++++++
 sim/configure.ac                      | 10 +++++++++
 sim/cris/arch.c                       |  5 +++--
 sim/cris/arch.h                       | 21 +++++++++++++-----
 sim/cris/cpuall.h                     |  5 +++--
 sim/cris/cpuv10.c                     |  6 +++--
 sim/cris/cpuv10.h                     |  5 +++--
 sim/cris/cpuv32.c                     |  6 +++--
 sim/cris/cpuv32.h                     |  5 +++--
 sim/cris/cris-tmpl.c                  |  2 ++
 sim/cris/decodev10.c                  | 21 +++++++++---------
 sim/cris/decodev10.h                  |  6 ++---
 sim/cris/decodev32.c                  | 21 +++++++++---------
 sim/cris/decodev32.h                  |  8 +++----
 sim/cris/modelv10.c                   |  5 +++--
 sim/cris/modelv32.c                   |  5 +++--
 sim/cris/semcrisv10f-switch.c         | 20 +++++++++++------
 sim/cris/semcrisv32f-switch.c         | 20 +++++++++++------
 sim/erc32/erc32.c                     | 28 +++++++++++------------
 sim/erc32/func.c                      | 14 ++++++------
 sim/erc32/sis.h                       |  8 +++----
 sim/frv/decode.c                      | 14 ++++++------
 sim/frv/sem.c                         |  4 ++++
 sim/frv/traps.c                       |  2 +-
 sim/h8300/compile.c                   |  4 ++--
 sim/iq2000/decode.c                   | 14 ++++++------
 sim/lm32/Makefile.in                  |  3 ---
 sim/lm32/cpu.h                        | 11 +++++++++
 sim/lm32/decode.c                     | 14 ++++++------
 sim/lm32/dv-lm32cpu.c                 |  3 +++
 sim/lm32/user.c                       |  3 +++
 sim/m32c/mem.c                        |  2 +-
 sim/m32r/decode.c                     | 14 ++++++------
 sim/m32r/decode2.c                    | 14 ++++++------
 sim/m32r/decodex.c                    | 14 ++++++------
 sim/m32r/m32r-sim.h                   | 24 +++++++++++++++-----
 sim/m32r/m32r2.c                      |  5 +++++
 sim/m32r/m32rx.c                      |  5 +++++
 sim/m32r/sim-if.c                     |  4 ++++
 sim/m32r/traps.c                      | 28 +++++++++++++++++++++--
 sim/mips/cp1.c                        |  8 +++----
 sim/mn10300/op_utils.c                |  5 +++--
 sim/or1k/decode.c                     | 14 ++++++------
 sim/ppc/altivec.igen                  |  2 +-
 sim/ppc/emul_netbsd.c                 |  4 +++-
 sim/ppc/emul_unix.c                   |  2 ++
 sim/ppc/hw_ide.c                      |  8 +++----
 sim/ppc/hw_phb.c                      |  2 +-
 sim/ppc/hw_sem.c                      |  4 ++--
 sim/ppc/igen.c                        |  2 +-
 sim/ppc/mon.c                         |  2 ++
 sim/ppc/sim_calls.c                   |  4 ++--
 sim/rx/rx.c                           |  2 +-
 sim/sh/gencode.c                      |  4 ++--
 sim/sh/interp.c                       |  4 +---
 62 files changed, 358 insertions(+), 206 deletions(-)


base-commit: 837e225ba1992f9745e5bbbd5e8443243a7f475f
  

On 20 Oct 2022 09:32, Tsukasa OI wrote:
> The led_off array used 0xB7 (Latin-1 middle dot) but it heavily depends on
> the source code encoding.  Directly using 0xB7 here is very dangerous and

"very dangerous" is questionable

> Clang causes a compiler warning ("-Winvalid-source-encoding").
> On the other hand, using '\u00b7' here will assume UTF-8.

we only care about UTF-8.  no other encoding (except ASCII) matters.

> As a workaround, this commit replaces uses of 0xB7 with '.'
> (regular ASCII dot).

i don't have a sense of what this code is meant to do.  is it just debug
output for devs staring at the console ?  probably because of the CSI
escape sequences here (\e[m).  if that's the case, i'm fine with changing
it.  i'll note that the RX port seems to use @ & * instead ...
-mike
  

On 2022/10/23 23:48, Mike Frysinger wrote:
> On 20 Oct 2022 09:32, Tsukasa OI wrote:
>> The led_off array used 0xB7 (Latin-1 middle dot) but it heavily depends on
>> the source code encoding.  Directly using 0xB7 here is very dangerous and
> 
> "very dangerous" is questionable

That's definitely an overreaction but forgive me since I'm from a
character encoding hell (Japan, which had at least three widely-used
pre-Unicode encodings).

> 
>> Clang causes a compiler warning ("-Winvalid-source-encoding").
>> On the other hand, using '\u00b7' here will assume UTF-8>
> we only care about UTF-8.  no other encoding (except ASCII) matters.

That's good to hear that.

> 
>> As a workaround, this commit replaces uses of 0xB7 with '.'
>> (regular ASCII dot).
> 
> i don't have a sense of what this code is meant to do.  is it just debug
> output for devs staring at the console ?  probably because of the CSI
> escape sequences here (\e[m).  if that's the case, i'm fine with changing
> it.  i'll note that the RX port seems to use @ & * instead ...
> -mike

I think this is a pseudo-LED output for console and middle dot (U+00B7)
is used to represent off and "O" is used to represent on.

It seems we can assume UTF-8 so I'll just re-encode this source file
with UTF-8.

Thanks,
Tsukasa