w64 cross, testsuite under wine, escape sequences
Host: x86_64-pc-linux (Cent 6) Target: x86_64-w64-mingw32 (wine) When I build the linux > w64 cross compiler under linux and run the testsuite under wine, it all basically works for the most part. However, the log files get filled with what appears to be ANSI escape sequences of the form: ^[[?1h^[=^[[?1l^[> For instance: ^[[?1h^[=^[[?1l^[>PASS: gcc.dg/ipa/ipa-pta-1.c execution test This generally doesn't cause a problem, except in the case of some fortran output pattern tests that try to patch ^string$. In that case, the regex fails, as it pulls in the escape sequences as part of "string". To run the testsuite under wine, I created a simulator board that uses "wine64" as the simulator that prefixes every spawned test. I ran this manually myself, and I do not get any extra characters, so I do not think that it's wine related. Does anyone have any experience with this, or suggestions on what to do?
Trampolines and descriptors
This came up in a discussion of an or1k patch, but it left me wondering so I'll raise the question again. Are function descriptors meaningful outside Ada? The internals manual seems to say yes, if enabled they will be used -- instead of trampolines -- also for C nested functions. Is that correct? It seems that this is worth using for any machine where it's desirable to avoid executing stack data. paul > On Aug 31, 2018, at 9:19 AM, Paul Koning wrote: > > > >> On Aug 30, 2018, at 9:02 PM, Jeff Law wrote: >> >> On 08/30/2018 10:58 AM, Richard Henderson wrote: >>> On 08/28/2018 07:13 AM, Jeff Law wrote: Please consider using function descriptors rather than trampolines. This allows you to make the stack non-executable at all times which is good from a security standpoint. The downside is the indirect calling mechanism has to change slightly to distinguish between a simple indirect call and one through a function descriptor (usually by having a low bit on to indicate the latter). GIven this is an ABI change, now is probably the last opportunity to make this change. >>> >>> Correct me if I'm wrong here: >>> >>> Define TARGET_CUSTOM_FUNCTION_DESCRIPTORS to an appropriate value -- easy >>> for a >>> RISC target -- and that's it. >>> >>> Further, it pretty much only gets used by the Ada front end. One should not >>> expect these to be used by the C front end nested functions. >> I thought it was used more extensively than that... Thanks for checking >> into it though. >> >> Jeff > > My impression from reading the internals manual is that it's an alternative > to trampolines -- and in fact it appears to suggest it's a superior > alternative. I've been planning to try turning it on for pdp11 where > executable stacks can be problematic. (For that matter, they are on lots of > other machines -- which is why descriptors instead of trampolines sounds like > a good thing.) > > paul >
Re: w64 cross, testsuite under wine, escape sequences
On Thu, Sep 6, 2018 at 9:08 AM NightStrike wrote:
>
> Host: x86_64-pc-linux (Cent 6)
> Target: x86_64-w64-mingw32 (wine)
>
> When I build the linux > w64 cross compiler under linux and run the
> testsuite under wine, it all basically works for the most part.
> However, the log files get filled with what appears to be ANSI escape
> sequences of the form:
>
> ^[[?1h^[=^[[?1l^[>
>
> For instance:
>
> ^[[?1h^[=^[[?1l^[>PASS: gcc.dg/ipa/ipa-pta-1.c execution test
>
> This generally doesn't cause a problem, except in the case of some
> fortran output pattern tests that try to patch ^string$. In that
> case, the regex fails, as it pulls in the escape sequences as part of
> "string".
>
> To run the testsuite under wine, I created a simulator board that uses
> "wine64" as the simulator that prefixes every spawned test. I ran
> this manually myself, and I do not get any extra characters, so I do
> not think that it's wine related.
>
> Does anyone have any experience with this, or suggestions on what to do?
It looks like this is definitely wine. Running it standalone under
strace shows this towards the end:
stat("/etc/terminfo", {st_mode=S_IFDIR|0755, st_size=2, ...}) = 0
access("/etc/terminfo/x/xterm-256color", R_OK) = -1 ENOENT (No such
file or directory)
stat("/usr/share/terminfo", {st_mode=S_IFDIR|0755, st_size=22, ...}) = 0
access("/usr/share/terminfo/x/xterm-256color", R_OK) = 0
open("/usr/share/terminfo/x/xterm-256color", O_RDONLY) = 10
read(10, "\32\1%\0&\0\17\0\235\1\251\5xterm-256color|xterm"..., 4097) = 3322
close(10) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=68, ws_col=209, ws_xpixel=0, ws_ypixel=0}) = 0
open("/proc/meminfo", O_RDONLY|O_CLOEXEC) = 10
fstat(10, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7ff2b72f9000
read(10, "MemTotal: 297772936 kB\nMem"..., 1024) = 1024
close(10) = 0
munmap(0x7ff2b72f9000, 4096)= 0
write(1, "\33", 1 = 1
write(1, "[", 1[)= 1
write(1, "?", 1?)= 1
write(1, "1", 11)= 1
write(1, "h", 1h)= 1
write(1, "\33", 1 = 1
write(1, "=", 1=)= 1
Any idea how to tell dejagnu to strip this out?
gcc-7-20180906 is now available
Snapshot gcc-7-20180906 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20180906/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 264151 You'll find: gcc-7-20180906.tar.xzComplete GCC SHA256=fed0a66daecece41d20a56238fc574d53312208e7a1b9a9933926fe7a0b21107 SHA1=4a02a3bdea059b7eeeba9af7da7176bd69f384a9 Diffs from 7-20180830 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
A possible gcc bug?
I am always wary of saying there might be a compiler bug - usually it is
a bug in the user code. But this time I am very suspicious. The
example here comes from a discussion in the comp.lang.c Usenet group.
Here is the code I have been testing:
unsigned char foo_u(unsigned int v) {
return (v & 0x7f) | (v & ~0x7f ? 0x80 : 0);
}
unsigned char foo_s(int v) {
return (v & 0x7f) | (v & ~0x7f ? 0x80 : 0);
}
unsigned char bar_s(int v) {
int x = v & 0x7f;
return (v & 0x7f) | (x ? 0x80 : 0);
}
int test_u_1(void) {
return foo_u(0x01); // Expect 0x01 = 1
}
int test_u_2(void) {
return foo_u(0x1001); // Expect 0x81 = 129
}
int test_s_1(void) {
return foo_s(0x01); // Expect 0x01 = 1
}
int test_s_2(void) {
return foo_s(0x1001); // Expect 0x81 = 129
}
The assembly code generated for this is:
foo_u(unsigned int):
mov edx, edi
and edx, 127
and edi, -128
cmp edi, 1
sbb eax, eax
not eax
and eax, -128
or eax, edx
ret
foo_s(int):
mov eax, edi
ret
bar_s(int):
mov edx, edi
and edx, 127
and edi, 127
cmp edi, 1
sbb eax, eax
not eax
and eax, -128
or eax, edx
ret
test_u_1():
mov eax, 1
ret
test_u_2():
mov eax, 129
ret
test_s_1():
mov eax, 1
ret
test_s_2():
mov eax, 1
ret
When the code uses "int" rather than "unsigned int", in "foo_s", the
compiler thinks the function can be optimised to a simple byte
extraction. I cannot see how that interpretation is valid. And gcc
cannot see it either, if there is an intermediate variable (in "bar_s").
(The type of the intermediate "x" in "bar_s" does not matter - "int",
"unsigned int", "auto", "__auto_type", const or not).
This effect is happening in the front-end. It is independent of
optimisation levels (-O gives the same results), the target processor (I
tried a half-dozen targets), the compiler version (from gcc 4.4 upwards
- gcc 4.1 gives the same code for foo_s as foo_u. I haven't tried gcc
4.2 or 4.3). The results from the compiler evaluations in the "test_"
functions shows that it this happens in the compiler analysis - it is
not a code generation issue.
is great for this kind of testing!
Is there something going wrong in gcc here, or is there something I am
missing?
mvh.,
David
