|
From: Jeff F. <jef...@gm...> - 2018-02-15 23:16:54
|
Was there a conscious decision to begin using 0b prefixes [more widely] in
3.14.0?
I'm trying to build 3.14.0 on/for an x86 linux box using gcc 4.1.2 (it's an
old FC7 distro that we're using for an embedded application). I pulled the
source from the repository using git, ran the autogen, followed by
"./configure prefix=$HOME/valgrind exec_prefix=$HOME/valgrind", and make.
The build chokes on a binary constant ("0b00010000") at line 1802
in priv/guest_s390_toIR.c:
priv/guest_s390_toIR.c:1802:43: error: invalid suffix "b00010000" on
integer constant
3.13.0 builds fine (though I didn't use git to pull it -- I just used the
source tarball).
I noticed that there are uses of the "0b" prefix in 3.13.0, but that seems
to be limited to the ARM architectures (where presumably all the SDKs are
relatively new and support "0b" use).
Would it be possible to avoid use of "0b" in the x86 flavors?
Thanks,
Jeff
|
|
From: Eliot M. <mo...@cs...> - 2018-02-18 02:24:12
|
On 2/15/2018 1:31 PM, Jeff Frontz wrote:
> Was there a conscious decision to begin using 0b prefixes [more widely] in 3.14.0?
>
>
> I'm trying to build 3.14.0 on/for an x86 linux box using gcc 4.1.2 (it's an old FC7 distro that
> we're using for an embedded application). I pulled the source from the repository using git, ran
> the autogen, followed by "./configure prefix=$HOME/valgrind exec_prefix=$HOME/valgrind", and make.
>
> The build chokes on a binary constant ("0b00010000") at line 1802 in priv/guest_s390_toIR.c:
>
> priv/guest_s390_toIR.c:1802:43: error: invalid suffix "b00010000" on integer constant
>
>
> 3.13.0 builds fine (though I didn't use git to pull it -- I just used the source tarball).
>
> I noticed that there are uses of the "0b" prefix in 3.13.0, but that seems to be limited to the ARM
> architectures (where presumably all the SDKs are relatively new and support "0b" use).
>
> Would it be possible to avoid use of "0b" in the x86 flavors?
AFAIK you just need a recent enough gcc for 0b to work. It *might* be affected
by which flags are given to gcc.
I can't speak to the intent on this point by the valgrind development community ...
Regards - Eliot Moss
|
|
From: Jeff F. <jef...@gm...> - 2018-02-20 01:58:01
|
On Sat, Feb 17, 2018 at 9:18 PM, Eliot Moss <mo...@cs...> wrote:
> On 2/15/2018 1:31 PM, Jeff Frontz wrote:
>
>>
>> I'm trying to build 3.14.0 on/for an x86 linux box using gcc 4.1.2
>>
>> The build chokes on a binary constant ("0b00010000") at line 1802
>> in priv/guest_s390_toIR.c:
>>
>> Would it be possible to avoid use of "0b" in the x86 flavors?
>>
>
> AFAIK you just need a recent enough gcc for 0b to work.
>
For sure. But the problem is when you're working in/on a legacy
environment that has been baselined/validated for use on a product for a
regulated industry, you can't just switch-up your SDK.
For that matter, it's not clear to me that any C standard actually
specifies the use of binary literals:
https://stackoverflow.com/questions/9014958/how-do-i-use-a-binary-prefix-in-accordance-with-c11
Jeff
|
|
From: John R. <jr...@bi...> - 2018-02-19 21:50:19
|
> Was there a conscious decision to begin using 0b prefixes [more widely] in 3.14.0? Yes. "0b" as prefix for binary numeral helps avoid errors in coding and understanding. This is particularly true when interpreting the encoding diagrams for instructions, as found in some CPU architecture reference manuals. > I'm trying to build 3.14.0 on/for an x86 linux box using gcc 4.1.2 (it's an old FC7 distro ... Use a newer compiler! Boot a recent "live" Linux distribution from USB flash memory on a x86_64 laptop computer, and build valgrind using "gcc -m32" etc. (Install a few software packages as necessary to complete the "i686" environment.) |