Am 29.06.2023 um 18:19 schrieb Mark Wielaard:
Hi Simon,
On Thu, Jun 29, 2023 at 05:46:59PM +0200, Simon Sobisch wrote:
Am 29.06.2023 um 15:10 schrieb John Reiser:
Running valgrind on GnuCOBOL errors out with
vex amd64->IR: unhandled instruction bytes:
0x62 0xF1 0xFE 0x8 0x6F 0x7 0x48
Hi Simon,
On Thu, Jun 29, 2023 at 05:46:59PM +0200, Simon Sobisch wrote:
> Am 29.06.2023 um 15:10 schrieb John Reiser:
> >>Running valgrind on GnuCOBOL errors out with
> >>
> >>vex amd64->IR: unhandled instruction bytes:
> >> 0x62 0xF1 0xFE 0x8 0x6F 0x7 0x48 0xC7 0x5 0x6F
> >>vex amd64->IR:
Sorry, I should have made this explicit!
The error initially was seen with
$> valgrind --version
valgrind-3.20.0
which was then updated to
$> valgrind --version
valgrind-3.21.0
where this output below (100% identical to 3.20.0) came from.
Both Valgrind and GnuCOBOL were compiled wit
Running valgrind on GnuCOBOL errors out with
vex amd64->IR: unhandled instruction bytes:
0x62 0xF1 0xFE 0x8 0x6F 0x7 0x48 0xC7 0x5 0x6F
vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE
vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0
va
Running valgrind on GnuCOBOL errors out with
vex amd64->IR: unhandled instruction bytes:
0x62 0xF1 0xFE 0x8 0x6F 0x7 0x48 0xC7 0x5 0x6F
vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE
vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0
val
On Wed, Apr 19, 2023 at 11:46:34AM +0200, folkert wrote:
> > > The 2 calls it does are:
> > >
> > > print_char:
> > > movb (%esi), %al
> > > movb %al, buffer
> > > movl $4, %eax
> > > movl $1, %ebx
> > > movl $buffer, %ecx
> > > movl $1, %edx
> > > int $0x80
> >
> > The 2 calls it does are:
> >
> > print_char:
> > movb (%esi), %al
> > movb %al, buffer
> > movl $4, %eax
> > movl $1, %ebx
> > movl $buffer, %ecx
> > movl $1, %edx
> > int $0x80
> > ret
> >
> > exit:
> > movl $1, %eax
> > movl $0, %ebx
> >
On 18/04/2023 17:46, folkert wrote:
The 2 calls it does are:
print_char:
movb (%esi), %al
movb %al, buffer
movl $4, %eax
movl $1, %ebx
movl $buffer, %ecx
movl $1, %edx
int $0x80
ret
exit:
movl $1, %eax
movl $0, %ebx
int $0x80
Valgrind
On 4/18/2023 10:51 AM, folkert wrote:
Hi,
I wrote a compiler for brainfuck to x86.
The result is quite fast but I was curious if I could tune it even more.
So I ran it in callgrind but this resulted in:
folkert@snsv ~/Projects/bf-compiler (master)$ valgrind --tool=callgrind ./test
==77043== Cal
> > I wrote a compiler for brainfuck to x86.
> > The result is quite fast but I was curious if I could tune it even more.
> > So I ran it in callgrind but this resulted in:
...
> > ==77043== Process terminating with default action of signal 4 (SIGILL)
> > ==77043== Illegal opcode at address 0x4027
Hi,
I wrote a compiler for brainfuck to x86.
The result is quite fast but I was curious if I could tune it even more.
So I ran it in callgrind but this resulted in:
folkert@snsv ~/Projects/bf-compiler (master)$ valgrind --tool=callgrind ./test
==77043== Callgrind, a call-graph generating cache pr
On 16/03/18 17:16, John Reiser wrote:
On 03/16/2018 1439 UTC, Zack Weinberg wrote:
On Fri, Mar 16, 2018 at 1323 UTC, John Reiser wrote:
The code 0x67 0xE8 0x7D 0xFF is "addr32 callq ...". Valgrind is
complaining
about the 'addr32' opcode prefix. The compiler for locale_init.cc did a
not-so
On 03/16/2018 1439 UTC, Zack Weinberg wrote:
On Fri, Mar 16, 2018 at 1323 UTC, John Reiser wrote:
The code 0x67 0xE8 0x7D 0xFF is "addr32 callq ...". Valgrind is complaining
about the 'addr32' opcode prefix. The compiler for locale_init.cc did a
not-so-good job. The addr32 prefix is a total
On Fri, Mar 16, 2018 at 9:23 AM, John Reiser wrote:
>
> The code 0x67 0xE8 0x7D 0xFF is "addr32 callq ...". Valgrind is complaining
> about the 'addr32' opcode prefix. The compiler for locale_init.cc did a
> not-so-good job. The addr32 prefix is a total waste; remove it.
This _could_ be an ali
On Fri, Mar 16, 2018 at 2:23 PM, John Reiser wrote:
> When I compile this simple C++ program as a 32-bit executable on a 64-bit
>> linux:
>>
>> #include
>> int main() {
>> std::cout << "Hello, World!" << std::endl;
>> return 0;
>> }
>>
>> Using the -m32 option:
>>
>> g++ -m32 o
The code 0x67 0xE8 0x7D 0xFF is "addr32 callq ...". Valgrind is complaining
about the 'addr32' opcode prefix. The compiler for locale_init.cc did a
not-so-good job. The addr32 prefix is a total waste; remove it.
Re-compile locale_init.cc with a better compiler.
Also fixed in https://bugs.kde
When I compile this simple C++ program as a 32-bit executable on a 64-bit linux:
#include
int main() {
std::cout << "Hello, World!" << std::endl;
return 0;
}
Using the -m32 option:
g++ -m32 out.cpp
Valgrind chokes on an supposedly illegal instruction:
vex x86->IR: unhandled
When I compile this simple C++ program as a 32-bit executable on a 64-bit
linux:
#include
int main() {
std::cout << "Hello, World!" << std::endl;
return 0;
}
Using the -m32 option:
g++ -m32 out.cpp
Valgrind chokes on an supposedly illegal instruction:
vex x86->IR: unhandled in
Hi Jeff,
I've downloaded and compiled gcc 4.4.7 (same as stock Centos version).
Unfortunately, the program no longer compiles, giving an error "This platform
does not support exception propagation". (I don't know what that means).
Any suggestion on how to get around this?
Thanks,
Danny
/home/
Hi Tom,
I omitted -march (didn't have -mcpu), but unfortunately exactly same error.
Now recompiling g++ 4.4.7 from source as per suggestion from Jeff Hammond.
Danny
On 29/11/2016, at 8:19 PM, Tom Hughes wrote:
>> For -march I've tried 'native', 'pentiumpro' and 'core2'.
>> When compiling for v
Super - thanks so much. Working on small emergency so will be able to get back
to this on Saturday. Fingers crossed.
Danny
On 29/11/2016, at 8:19 PM, Tom Hughes wrote:
>> For -march I've tried 'native', 'pentiumpro' and 'core2'.
>> When compiling for valgrind, also -O0.
>
> Well native is de
On 29/11/16 12:10, Danny Wilson wrote:
> For -march I've tried 'native', 'pentiumpro' and 'core2'.
> When compiling for valgrind, also -O0.
Well native is definitely not going to work, and core2 might be pushing
it, but pentiumpro should be fine. To be honest just leaving out -march
and -mcpu s
Hi Tom,
For -march I've tried 'native', 'pentiumpro' and 'core2'.
When compiling for valgrind, also -O0.
# cat /etc/redhat-release
CentOS release 6.6 (Final)
# uname -a
Linux dvstor5 3.10.80-1.el6.elrepo.i686 #1 SMP Sun Jun 7 08:15:14 EDT 2015 i686
i686 i386 GNU/Linux
Danny
On 29/11/2016, at
Hi Jeff,
Thanks, I'll give it a shot!
From the previous messages in this thread, the target machine is an 6500 series
i5. When rebuilding gcc, what value for -march would be appropriate?
Danny
On 29/11/2016, at 12:35 PM, Jeff Hammond wrote:
> Based upon your prior report showing the illegal
On 29/11/16 09:42, Alex Bligh wrote:
>> On 29 Nov 2016, at 01:29, Danny Wilson wrote:
>>
>> Hi Alex, rebuilding the standard libraries is a little beyond our scope (and
>> I'd figure it unlikely that such a basic function of the c++ library had a
>> memory leak. Something like that would be we
Danny,
> On 29 Nov 2016, at 01:29, Danny Wilson wrote:
>
> Hi Alex, rebuilding the standard libraries is a little beyond our scope (and
> I'd figure it unlikely that such a basic function of the c++ library had a
> memory leak. Something like that would be well published). As Tom pointed
>
On Mon, Nov 28, 2016 at 5:29 PM, Danny Wilson wrote:
> On 28/11/2016, at 8:07 PM, Alex Bligh wrote:
> >
> >> On 27 Nov 2016, at 16:09, Danny Wilson wrote:
> >>
> >> The target machines uses an i5 CPU but the build machine is a core2 duo
> which is why I chose 'native'. Not sure that was the rig
On 28/11/2016, at 8:07 PM, Alex Bligh wrote:
>
>> On 27 Nov 2016, at 16:09, Danny Wilson wrote:
>>
>> The target machines uses an i5 CPU but the build machine is a core2 duo
>> which is why I chose 'native'. Not sure that was the right choice but it
>> works (without Valgrind).
>>
>> I've ju
> On 27 Nov 2016, at 16:09, Danny Wilson wrote:
>
> The target machines uses an i5 CPU but the build machine is a core2 duo which
> is why I chose 'native'. Not sure that was the right choice but it works
> (without Valgrind).
>
> I've just tried -march as 'native', 'core2', and 'pentiumpro'
The target machines uses an i5 CPU but the build machine is a core2 duo which
is why I chose 'native'. Not sure that was the right choice but it works
(without Valgrind).
I've just tried -march as 'native', 'core2', and 'pentiumpro'. All have the
same result.
(and you are right: the SIGILL h
On 27/11/16 10:28, Danny Wilson wrote:
> The build machine is a core2 duo running 32-bit Centos 6.6 and custom
> kernel 3.10.
>
> I recompiled the app using --march=native and --march=pentiumpro, but
> got the same error.
Don't use -march=native - that is telling the compiler to use everything
m
Hi Jeff,
I put a SIGILL handler in. Running normally without valgrind shows the signal
is caught and ignored (when kill -ILL is sent)
But it seems that valgrind is disabling my signal handler. Running under
valgrind still exits with
> Valgrind will now raise a SIGILL signal which will proba
The build machine is a core2 duo running 32-bit Centos 6.6 and custom kernel
3.10.
I recompiled the app using --march=native and --march=pentiumpro, but got the
same error.
I'll try the SIGKILL handler now.
Danny
> vex x86->IR: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45
> ==29426== valg
On 27/11/16 03:46, Danny Wilson wrote:
> It is a huge application, 1.5M lines not including big external dependencies
> like ACE/TAO. Porting over to 64bit mode would probably take months. Any
> other suggestion? Perhaps disabling the generation of the offending AVX
> instructions with some co
Hi Tom,
Thanks for the response.
It is a huge application, 1.5M lines not including big external dependencies
like ACE/TAO. Porting over to 64bit mode would probably take months. Any other
suggestion? Perhaps disabling the generation of the offending AVX instructions
with some compiler flag?
> Thanks for the response.
>
> It is a huge application, 1.5M lines not including big external dependencies
> like ACE/TAO. Porting over to 64bit mode would probably take months. Any
> other suggestion? Perhaps disabling the generation of the offending AVX
> instructions with some compiler flag
On 26/11/16 15:36, Jeffrey Walton wrote:
> On Fri, Nov 25, 2016 at 9:38 PM, Danny Wilson wrote:
>> I am trying to find a memory leak in a large C++ program which utilizes
>> multiple shared libraries.
>>
>> Unfortunately, valgrind fails with "unhandled instruction bytes: 0xC5 0xF9
>> 0x6E 0x45"
>>
On Fri, Nov 25, 2016 at 9:38 PM, Danny Wilson wrote:
> I am trying to find a memory leak in a large C++ program which utilizes
> multiple shared libraries.
>
> Unfortunately, valgrind fails with "unhandled instruction bytes: 0xC5 0xF9
> 0x6E 0x45"
>
> It says the illegal instruction is inside std:
I am trying to find a memory leak in a large C++ program which utilizes
multiple shared libraries.
Unfortunately, valgrind fails with "unhandled instruction bytes: 0xC5 0xF9 0x6E
0x45"
It says the illegal instruction is inside std::tr1::__detail, inside a standard
library...
Is there anything
This has been fixed in the trunk. You can check out and build it
easily using the instructions shown at
http://www.valgrind.org/downloads/repository.html
J
On Monday, August 16, 2010, Gaetano Mendola wrote:
> Hi all,
> I'm using valgrind-3.6.0.SVN-Debian installed on my ubuntu distribution,
>
Hi all,
I'm using valgrind-3.6.0.SVN-Debian installed on my ubuntu distribution,
and I'm getting the error:
vex amd64->IR: unhandled instruction bytes: 0xF3 0x48 0xF 0xB8 0xC0 0x48
is there a way to ignore it ?
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
---
41 matches
Mail list logo
