GithubHelp home page GithubHelp logo

go test error in mips64le about term HOT 1 CLOSED

pkg avatar pkg commented on July 29, 2024
go test error in mips64le

from term.

Comments (1)

daniel-santos avatar daniel-santos commented on July 29, 2024

@Doorer Can you please specify which libc you are using?

Hello all! I was just about to open an issue for this. I'm getting the same thing on mipsel linux-4.14-120 and musl-1.1.24 for my libc -- this is 32-bit and I'm building from OpenWRT v19.07 branch. I'm using go-1.13.15. For the sake of clarity, this arch is also known as "mips32 release 2 " using the "old" ABI ("o32" as opposed to "n32"). When an arch says just "mips", it usually means exactly this mips32 release 2 old ABI, while "mipsn32" means the same except the new ABI.

Anyway, I'm green in Go, so I won't help much there, but note that there's an original and extra crispy: termios and termios2. This gets messier because there are the kernel-generated user headers that have them separated and then there's the libc headers, which can differ.

In my OpenWRT tree, this file is under build_dir/toolchain-mipsel_24kc_gcc-8.3.0_musl/musl-1.1.24/arch/mips/bits/termios.h. musl's <termios.h> includes it's own <bits/termios.h> which defines it like this:

struct termios {
        tcflag_t c_iflag;
        tcflag_t c_oflag;
        tcflag_t c_cflag;
        tcflag_t c_lflag;
        cc_t c_line;
        cc_t c_cc[NCCS];
        speed_t __c_ispeed;
        speed_t __c_ospeed;
};

I have checked the latest musl head and this has not changed since 1.2.1. I'm really not sure why they are there, because no musl code uses them and they don't match up with termios2 -- in fact they differ quite a bit from the kernel-generated user headers:

typedef unsigned char cc_t;
typedef unsigned int speed_t;
typedef unsigned int tcflag_t;

/*
 * The ABI says nothing about NCC but seems to use NCCS as
 * replacement for it in struct termio
 */
#define NCCS    23
struct termios {
        tcflag_t c_iflag;               /* input mode flags */
        tcflag_t c_oflag;               /* output mode flags */
        tcflag_t c_cflag;               /* control mode flags */
        tcflag_t c_lflag;               /* local mode flags */
        cc_t c_line;                    /* line discipline */
        cc_t c_cc[NCCS];                /* control characters */
};

struct termios2 {
        tcflag_t c_iflag;               /* input mode flags */
        tcflag_t c_oflag;               /* output mode flags */
        tcflag_t c_cflag;               /* control mode flags */
        tcflag_t c_lflag;               /* local mode flags */
        cc_t c_line;                    /* line discipline */
        cc_t c_cc[NCCS];                /* control characters */
        speed_t c_ispeed;               /* input speed */
        speed_t c_ospeed;               /* output speed */
};

struct ktermios {
        tcflag_t c_iflag;               /* input mode flags */
        tcflag_t c_oflag;               /* output mode flags */
        tcflag_t c_cflag;               /* control mode flags */
        tcflag_t c_lflag;               /* local mode flags */
        cc_t c_line;                    /* line discipline */
        cc_t c_cc[NCCS];                /* control characters */
        speed_t c_ispeed;               /* input speed */
        speed_t c_ospeed;               /* output speed */
};

As per the C standard, names beginning with_ are reserved for the compiler and beginning with __ are reserved for the libc implementation, so the way musl defined it is technically legitimate. But what should be followed is the POSIX standard (2018 edition)! As you can see here, it doesn't define ispeed or ospeed, so we should not depend upon these being there.

Also, if it looks like something else is the root cause of the problem, don't be afraid to report issues upstream and blame them. :) But in this case, I think the dependence upon Ispeed and Ospeed fields is the error.

from term.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.