|
From: Julian S. <js...@ac...> - 2005-07-27 20:17:51
|
Greetings. Valgrind-3.0.0 Release Candidate 1 is available from http://www.valgrind.org/downloads/valgrind-3.0.RC1.tar.bz2 (md5sum == c3dc8089bebe7aba0822667b7850451e) This is our first attempt at what we believe to be a release-quality snapshot of the Valgrind-3.0 line. If all goes well, we hope to release a final 3.0 in about a week's time. This is the first Valgrind to support both x86-linux and amd64-linux. Support for ppc32-linux is also integrated but does not yet work well enough to be useful. Please download and test this release candidate, and let us know of any problems you encounter. This tarball is known to build and work on the following platforms: amd64 running SuSE 9.2 x86 running SuSE 9.1, SuSE 9.3, RedHat 7.3, Fedora Core 4 ppc32 running Yellow Dog 4.0.1 (subject to caveats above) The attached release notes detail what is new in 3.0. Many thanks to all those who contributed to Valgrind's development. This RC represents a great deal of time, energy and effort on the part of many people. The Valgrind Developers --------------------------------------------------------------------- Release 3.0.0 ([[TODO: add release date]]) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.0.0 is a major overhaul of Valgrind. The most significant user-visible change is that Valgrind now supports architectures other than x86. The new architectures it supports are AMD64 and PPC32, and the infrastructure is present for other architectures to be added later. The AMD64 support works well, but has some shortcomings: - It generally won't be as solid as the x86 version. For example, support for more obscure instructions and system calls may be missing. We will fix these as they arise. - Address space may be limited; see the point about position-independent executables below. - If Valgrind is built on an AMD64 machine, it will only run 64-bit executables. If you want to run 32-bit x86 executables under Valgrind on an AMD64, you will need to build Valgrind on an x86 machine and copy it to the AMD64 machine. And it probably won't work if you do something tricky like exec'ing a 32-bit program from a 64-bit program while using --trace-children=yes. We hope to improve this situation in the future. The PPC32 support is very basic. It may not work reliably even for small programs, but it's a start. Many thanks to Paul Mackerras for his great work that enabled this support. We are working to make PPC32 usable as soon as possible. Other user-visible changes: - No longer building Valgrind as a position-independent executable (PIE) by default, as it caused too many problems. Without PIE enabled, AMD64 programs will only be able to access 2GB of address space. We will fix this eventually, but not for the moment. Use --enable-pie at configure-time to turn this on. - Support for programs that use stack-switching has been improved. Use the --max-stackframe flag for simple cases, and the VALGRIND_STACK_REGISTER, VALGRIND_STACK_DEREGISTER and VALGRIND_STACK_CHANGE client requests for trickier cases. - Support for programs that use self-modifying code has been improved, in particular programs that put temporary code fragments on the stack. This helps for C programs compiled with GCC that use nested functions, and also Ada programs. This is controlled with the --smc-check flag, although the default setting should work in most cases. - Output can now be printed in XML format. This should make it easier for tools such as GUI front-ends and automated error-processing schemes to use Valgrind output as input. The --xml flag controls this. As part of this change, ELF directory information is read from executables, so absolute source file paths are available if needed. [[TODO: describe the related CLOs added (eg. --log-file-qualifier)]] - Programs that allocate many heap blocks may run faster, due to improvements in certain data structures. - Addrcheck is currently not working. We hope to get it working again soon. Helgrind is still not working, as was the case for the 2.4.0 release. - The JITter has been completely rewritten, and is now in a separate library, called Vex. This enabled a lot of the user-visible changes, such as new architecture support. The new JIT unfortunately translates more slowly than the old one, so programs may take longer to start. We believe the code quality is produces is about the same, so once started, programs should run at about the same speed. Feedback about this would be useful. On the plus side, Vex and hence Memcheck tracks value flow properly through floating point and vector registers, something the 2.X line could not do. That means that Memcheck is much more likely to be usably accurate on vectorised code. - There is a subtle change to the way exiting of threaded programs is handled. In 3.0, Valgrind's final diagnostic output (leak check, etc) is not printed until the last thread exits. If the last thread to exit was not the original thread which started the program, any other process wait()-ing on this one to exit may conclude it has finished before the diagnostic output is printed. This may not be what you expect. 2.X had a different scheme which avoided this problem, but caused deadlocks under obscure circumstances, so we are trying something different for 3.0. - Small changes in control log file naming which make it easier to use valgrind for debugging MPI-based programs. - As part of adding AMD64 support, DWARF2 CFI-based stack unwinding support was added. In principle this means Valgrind can produce meaningful backtraces on x86 code compiled with -fomit-frame-pointer providing you also compile your code with -fasynchronous-unwind-tables. - [[TODO: add more here]] Changes that are not user-visible: - The code has been massively overhauled in order to modularise it. As a result we hope it is easier to navigate and understand. - Lots of code has been rewritten. - [[TODO: add more here]] BUGS FIXED [[TODO: add the full list here (once the RCs are out of the way?)]] (3.0RC1: 27 July 05, vex r1303, valgrind r4283). |
|
From: Michael S. <mlr...@gm...> - 2005-07-28 14:37:47
|
On 7/27/05, Julian Seward <js...@ac...> wrote: >=20 > Greetings. >=20 > Valgrind-3.0.0 Release Candidate 1 is available from > http://www.valgrind.org/downloads/valgrind-3.0.RC1.tar.bz2 > (md5sum =3D=3D c3dc8089bebe7aba0822667b7850451e) Oops. This was meant to go to the list, not just Julian... Let's try again! I tried this out on an application of mine, and got this: unhandled opc_aux =3D 0x 3 first_opcode =3D=3D 0xDA vex x86->IR: unhandled instruction bytes: 0xDA 0x1C 0x24 0xDF =3D=3D24821=3D=3D =3D=3D24821=3D=3D Process terminating with default action of signal 4 (SIGI= LL) =3D=3D24821=3D=3D Illegal opcode at address 0x1BA168D8 =3D=3D24821=3D=3D at 0x1BA168D8: floor1_fit (floor1.c:581) =3D=3D24821=3D=3D by 0x1BA19F04: mapping0_forward (mapping0.c:497) =3D=3D24821=3D=3D by 0x1BA0EC66: vorbis_analysis (analysis.c:49) =3D=3D24821=3D=3D by 0x8048F2E: main (encoder_example.c:220) =3D=3D24821=3D=3D This was late in execution, and a LOT of errors had already been reported (most of them in tight loops), so I'm not sure whether it's a real problem, or if my application had already done something Very Bad like writing to random areas of memory. This system is 32 bit x86, running the current Ubuntu development release (which uses gcc 4 as the default compiler - the problem I'm looking into in this application is specific to gcc4). Mike p.s. Thanks for valgrind, it's been an invaluable tool. |
|
From: Tom H. <to...@co...> - 2005-07-28 14:50:32
|
In message <3c1...@ma...>
Michael Smith <mlr...@gm...> wrote:
> On 7/27/05, Julian Seward <js...@ac...> wrote:
>>
>> Greetings.
>>
>> Valgrind-3.0.0 Release Candidate 1 is available from
>> http://www.valgrind.org/downloads/valgrind-3.0.RC1.tar.bz2
>> (md5sum == c3dc8089bebe7aba0822667b7850451e)
>
> Oops. This was meant to go to the list, not just Julian... Let's try again!
As it happens, Julian is best placed to deal with unhandled
instructions. Even better is to enter a bug on the bug tracker.
> I tried this out on an application of mine, and got this:
>
> unhandled opc_aux = 0x 3
> first_opcode == 0xDA
> vex x86->IR: unhandled instruction bytes: 0xDA 0x1C 0x24 0xDF
> ==24821==
> ==24821== Process terminating with default action of signal 4 (SIGILL)
> ==24821== Illegal opcode at address 0x1BA168D8
> ==24821== at 0x1BA168D8: floor1_fit (floor1.c:581)
> ==24821== by 0x1BA19F04: mapping0_forward (mapping0.c:497)
> ==24821== by 0x1BA0EC66: vorbis_analysis (analysis.c:49)
> ==24821== by 0x8048F2E: main (encoder_example.c:220)
> ==24821==
That's the x87 FICOMP instruction, so this is similar to bug #103594
which is about the FICOM instruction.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Michael S. <mlr...@gm...> - 2005-07-28 15:03:56
|
On 7/28/05, Tom Hughes <to...@co...> wrote: > As it happens, Julian is best placed to deal with unhandled > instructions. Even better is to enter a bug on the bug tracker. Ok. >=20 > That's the x87 FICOMP instruction, so this is similar to bug #103594 > which is about the FICOM instruction. I've added my information to this bug report, since the instructions are closely related. Thanks for your help. Mike |
|
From: Duane G. <d.g...@ps...> - 2005-07-29 11:59:48
|
On Wed, 2005-07-27 at 21:17 +0100, Julian Seward wrote: > Greetings. > > Valgrind-3.0.0 Release Candidate 1 is available from > http://www.valgrind.org/downloads/valgrind-3.0.RC1.tar.bz2 > (md5sum == c3dc8089bebe7aba0822667b7850451e) [snip] > Please download and test this release candidate, and let us know of > any problems you encounter. This tarball is known to build and work > on the following platforms: > > amd64 running SuSE 9.2 > > x86 running SuSE 9.1, SuSE 9.3, RedHat 7.3, Fedora Core 4 > > ppc32 running Yellow Dog 4.0.1 (subject to caveats above) It builds and seems to work fine for me on AMD64 running SuSE 9.0, but there are a number of failures in the regression test: == 157 tests, 35 stderr failures, 1 stdout failure ================= memcheck/tests/leakotron (stdout) memcheck/tests/mismatches (stderr) memcheck/tests/new_nothrow (stderr) memcheck/tests/new_override (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/weirdioctl (stderr) none/tests/amd64/insn_fpu (stderr) none/tests/amd64/insn_mmx (stderr) none/tests/amd64/insn_sse (stderr) none/tests/amd64/insn_sse2 (stderr) none/tests/coolo_sigaction (stderr) none/tests/faultstatus (stderr) none/tests/floored (stderr) none/tests/gxx304 (stderr) none/tests/manythreads (stderr) none/tests/mq (stderr) none/tests/pth_atfork1 (stderr) none/tests/pth_blockedsig (stderr) none/tests/pth_cancel1 (stderr) none/tests/pth_cancel2 (stderr) none/tests/pth_cvsimple (stderr) none/tests/pth_empty (stderr) none/tests/pth_exit (stderr) none/tests/pth_exit2 (stderr) none/tests/pth_mutexspeed (stderr) none/tests/pth_once (stderr) none/tests/pth_rwlock (stderr) none/tests/pth_stackalign (stderr) none/tests/res_search (stderr) none/tests/semlimit (stderr) none/tests/thread-exits (stderr) none/tests/threaded-fork (stderr) none/tests/threadederrno (stderr) Cheers, Duane. -- Duane Griffin Senior Software Developer Process Systems Enterprise Limited - "The model company" Bridge Studios, 107a Hammersmith Bridge Road, London W6 9DA Call +44 (0)20 8563 0888 or visit us at www.psenterprise.com |
|
From: Nicholas N. <nj...@cs...> - 2005-07-29 14:25:10
|
On Fri, 29 Jul 2005, Duane Griffin wrote: > It builds and seems to work fine for me on AMD64 running SuSE 9.0, but > there are a number of failures in the regression test: > > == 157 tests, 35 stderr failures, 1 stdout failure ================= 35 is a bit high. Can you look at the *.stderr.diff and *.stderr.out files and determine if there's a single cause of most of the failures? Thanks. N |
|
From: Maurice v. d. P. <gri...@ge...> - 2005-07-31 13:32:36
|
On Fri, Jul 29, 2005 at 09:25:01AM -0500, Nicholas Nethercote wrote: > On Fri, 29 Jul 2005, Duane Griffin wrote: >=20 > >It builds and seems to work fine for me on AMD64 running SuSE 9.0, but > >there are a number of failures in the regression test: > > > >=3D=3D 157 tests, 35 stderr failures, 1 stdout failure =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 35 is a bit high. Can you look at the *.stderr.diff and *.stderr.out=20 > files and determine if there's a single cause of most of the failures? I have similar results on an x86 running Gentoo: =3D=3D 180 tests, 31 stderr failures, 2 stdout failures =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D memcheck/tests/addressable (stderr) memcheck/tests/badaddrvalue (stderr) memcheck/tests/badrw (stderr) memcheck/tests/clientperm (stderr) memcheck/tests/custom_alloc (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/errs1 (stderr) memcheck/tests/exitprog (stderr) memcheck/tests/fprw (stderr) memcheck/tests/inits (stderr) memcheck/tests/inline (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/manuel1 (stderr) memcheck/tests/manuel3 (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/strchr (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp2 (stderr) memcheck/tests/suppfree (stderr) memcheck/tests/trivialleak (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/x86/pushfpopf (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_exit_group (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mq (stderr) none/tests/selfrun (stdout) none/tests/selfrun (stderr) none/tests/x86/int (stderr) There does not seem to be a single cause of most of these.=20 I see unhandled instructions, an unimplemented function (mq_open), a bad cmdline option (--single-step=3Dyes), lots of expected __libc_start_main messages that are not generated, source line differences, etc. I'll be happy to provide whatever extra info you need. Maurice. --=20 Maurice van der Pot Gentoo Linux Developer gri...@ge... http://www.gentoo.org Creator of BiteMe! gri...@kf... http://www.kfk4ever.com |
|
From: Maurice v. d. P. <gri...@ge...> - 2005-07-29 17:46:15
Attachments:
valgrind-3.0.0-static-const.patch
|
On Wed, Jul 27, 2005 at 09:17:35PM +0100, Julian Seward wrote:
> Please download and test this release candidate, and let us know of
> any problems you encounter.
It compiles on one of my systems, but not on the other. The system that
it fails to build on is an nptl only system.
The build fails because of a few static const variable declarations
within functions. Why are these static? If I change them to normal const
variables, the compilation succeeds.
One example of this is in coregrind/m_aspacemgr/aspacemgr.c at the
beginning of function VG_(unmap_range). The error I get is
"initializer element is not constant".
I've tried with
compilers: gcc 3.3.3
gcc 3.4.3
gcc 3.4.4
glibc: 2.3.5
Attached is a patch to change all problematic static consts into consts.
Best regards,
Maurice.
P.S.: If proc is not mounted, valgrind exits like this:
open /proc/self/maps: No such file or directory
Segmentation fault
It would be nice if it could exit more gracefully.
--
Maurice van der Pot
Gentoo Linux Developer gri...@ge... http://www.gentoo.org
Creator of BiteMe! gri...@kf... http://www.kfk4ever.com
|
|
From: Tom H. <to...@co...> - 2005-07-29 17:58:51
|
In message <200...@kf...>
Maurice van der Pot <gri...@ge...> wrote:
> It compiles on one of my systems, but not on the other. The system that
> it fails to build on is an nptl only system.
I don't think the NPTL only thing is an issue. FC4 is NPTL by default
and that builds fine.
> The build fails because of a few static const variable declarations
> within functions. Why are these static? If I change them to normal const
> variables, the compilation succeeds.
The problem is not the fact that it is static, but the fact that
the initialiser is invalid.
> One example of this is in coregrind/m_aspacemgr/aspacemgr.c at the
> beginning of function VG_(unmap_range). The error I get is
> "initializer element is not constant".
Those are technically invalid but work with every version of gcc
that I know of so long as you have optimisation turned on as the
constant folder reduces the expression to a constant before it checks
the initialiser ;-)
For production use I would suggest that you probably want to have
optimisation turned on when building valgrind
> I've tried with
> compilers: gcc 3.3.3
> gcc 3.4.3
> gcc 3.4.4
> glibc: 2.3.5
>
> Attached is a patch to change all problematic static consts into consts.
There is already a bug on the bug tracker for this. You probably
want to attach yourself to it and maybe add your patch.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Maurice v. d. P. <gri...@ge...> - 2005-07-29 18:17:42
|
On Fri, Jul 29, 2005 at 06:58:43PM +0100, Tom Hughes wrote: > > The build fails because of a few static const variable declarations > > within functions. Why are these static? If I change them to normal const > > variables, the compilation succeeds. >=20 > The problem is not the fact that it is static, but the fact that > the initialiser is invalid. I'd like to understand this. The initialiser is False || somestaticconstfil= evar.=20 Why would that be a problem only for static consts and not for consts?=20 What is the difference between static consts and consts within functions=20 for that matter? > For production use I would suggest that you probably want to have > optimisation turned on when building valgrind You're right. I forgot to check this. > There is already a bug on the bug tracker for this. You probably > want to attach yourself to it and maybe add your patch. Oh man! I'm the one who submitted the report! When I saw this problem this time I knew I had seen it before, but I searched through Gentoo's bugzilla and any patches I ever applied to my packages and didn't find anything.=20 Sorry for the duplicate report. I attached the patch to the bug report. Thanks, Maurice. --=20 Maurice van der Pot Gentoo Linux Developer gri...@ge... http://www.gentoo.org Creator of BiteMe! gri...@kf... http://www.kfk4ever.com |
|
From: Tom H. <to...@co...> - 2005-07-29 18:30:17
|
In message <200...@kf...>
Maurice van der Pot <gri...@ge...> wrote:
> On Fri, Jul 29, 2005 at 06:58:43PM +0100, Tom Hughes wrote:
> > > The build fails because of a few static const variable declarations
> > > within functions. Why are these static? If I change them to normal const
> > > variables, the compilation succeeds.
> >
> > The problem is not the fact that it is static, but the fact that
> > the initialiser is invalid.
>
> I'd like to understand this. The initialiser is False || somestaticconstfilevar.
> Why would that be a problem only for static consts and not for consts?
> What is the difference between static consts and consts within functions
> for that matter?
Whether it is const or not is irrelevant, the fact is that the
initialiser for a static variable (whether or not it is const and
whether it is at file or function scape) is supposed to be a constant.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Paul P. <ppl...@gm...> - 2005-07-30 00:47:33
|
On AMD64 Red Hat Enterprise Linux AS release 3 (Taroon Update 2),
gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-39)
make check fails to build:
/home/paul/valgrind-3.0.RC1/tests/cputest.c:103: undefined reference to `go=
'
collect2: ld returned 1 exit status
This is because this gcc uses -D__x86_64 rather then -D__amd64
Fix:
--- cputest.c.orig 2005-07-29 17:23:48.000000000 -0700
+++ cputest.c 2005-07-29 17:24:35.000000000 -0700
@@ -21,7 +21,7 @@
NULL
};
=20
-#ifdef __amd64
+#if defined(__amd64) || defined(__x86_64)
static Bool go(char* cpu)
{
if ( strcmp( cpu, "amd64" ) =3D=3D 0 )
Most of the tests fail:
=3D=3D 157 tests, 149 stderr failures, 2 stdout failures =3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
memcheck/tests/addressable (stderr)
memcheck/tests/badaddrvalue (stderr)
memcheck/tests/badfree-2trace (stderr)
memcheck/tests/badfree (stderr)
memcheck/tests/badjump (stderr)
memcheck/tests/badjump2 (stderr)
...
Looks like most of them are failing due to=20
Warning: zero-sized CIE/FDE but not at section end in DWARF2 CFI reading
which I reported earlier.
The 2 stdout failures are:
memcheck/tests/leakotron.stdout.diff:
*** leakotron.stdout.exp 2005-07-26 01:58:06.000000000 -0700
--- leakotron.stdout.out 2005-07-29 17:27:08.000000000 -0700
***************
*** 1 ****
! PASS
--- 1 ----
! FAILED: I freed everything, but there's still 4800 bytes reachable
none/tests/exec-sigmask.stdout.diff
*** exec-sigmask.stdout.exp 2005-07-26 01:58:34.000000000 -0700
--- exec-sigmask.stdout.out 2005-07-29 17:28:30.000000000 -0700
***************
*** 0 ****
--- 1 ----
+ full: signal 32 missing from mask
Cheers,
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-30 01:24:45
|
On Fri, 29 Jul 2005, Paul Pluzhnikov wrote: > make check fails to build: > /home/paul/valgrind-3.0.RC1/tests/cputest.c:103: undefined reference to `go' > collect2: ld returned 1 exit status > > This is because this gcc uses -D__x86_64 rather then -D__amd64 I've committed a fix for this, thanks. N |
|
From: Nicholas N. <nj...@cs...> - 2005-08-03 13:22:05
|
On Fri, 29 Jul 2005, Paul Pluzhnikov wrote: > make check fails to build: > /home/paul/valgrind-3.0.RC1/tests/cputest.c:103: undefined reference to `go' > collect2: ld returned 1 exit status > > This is because this gcc uses -D__x86_64 rather then -D__amd64 I fixed that the other day. > Most of the tests fail: > == 157 tests, 149 stderr failures, 2 stdout failures ================= > memcheck/tests/addressable (stderr) > memcheck/tests/badaddrvalue (stderr) > memcheck/tests/badfree-2trace (stderr) > memcheck/tests/badfree (stderr) > memcheck/tests/badjump (stderr) > memcheck/tests/badjump2 (stderr) > ... > > Looks like most of them are failing due to > Warning: zero-sized CIE/FDE but not at section end in DWARF2 CFI reading > which I reported earlier. Julian fixed that, too. N |
|
From: Paul P. <ppl...@gm...> - 2005-08-03 16:17:37
|
On 8/3/05, Nicholas Nethercote <nj...@cs...> wrote:
> > Warning: zero-sized CIE/FDE but not at section end in DWARF2 CFI readi=
ng
>=20
> Julian fixed that, too.
The new regtest results from that system:
=3D=3D 159 tests, 8 stderr failures, 1 stdout failure =3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
memcheck/tests/leakotron (stdout)
memcheck/tests/pointer-trace (stderr)
memcheck/tests/sigprocmask (stderr)
memcheck/tests/strchr (stderr)
memcheck/tests/vgtest_ume (stderr)
memcheck/tests/weirdioctl (stderr)
memcheck/tests/xml1 (stderr)
none/tests/faultstatus (stderr)
none/tests/fdleak_fcntl (stderr)
The "interesting" diffs are:
*** vgtest_ume.stderr.exp 2005-07-02 15:43:03.000000000 -0700
--- vgtest_ume.stderr.out 2005-08-03 07:41:05.000000000 -0700
***************
*** 4 ****
! Hello, world!
--- 4,5 ----
! Warning: client syscall mmap2 tried to modify addresses 0x........-0x....=
....
! valgrind: mmap(0x........, 4096) failed in UME.
*** weirdioctl.stderr.exp 2005-07-02 15:42:58.000000000 -0700
--- weirdioctl.stderr.out 2005-08-03 07:41:06.000000000 -0700
***************
*** 3,4 ****
! by 0x........: __libc_start_main (in /...libc...)
! by 0x........: ...
--- 3,8 ----
! by 0x........: main (weirdioctl.c:28)
! Address 0x........ is on thread 1's stack
!=20
! Syscall param ioctl(TCSET{A,AW,AF}) points to uninitialised byte(s)
! at 0x........: ioctl (in /...libc...)
! by 0x........: main (weirdioctl.c:43)
*** xml1.stderr.exp64 2005-08-03 07:33:52.000000000 -0700
--- xml1.stderr.out 2005-08-03 07:41:09.000000000 -0700
***************
*** 353,364 ****
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>__libc_start_main</fn>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <dir>...</dir>
- <file>start.S</file>
- <line>...</line>
- </frame>
--- 352 ----
*** faultstatus.stderr.exp 2005-07-02 15:43:44.000000000 -0700
--- faultstatus.stderr.out 2005-08-03 07:41:37.000000000 -0700
***************
*** 6,12 ****
- Test 5: PASS
- Test 6: PASS
- Test 7: PASS
- Test 8: PASS
- Test 9: disInstr: unhandled instruction bytes: 0x........ 0x........
0x........ 0x........
- at 0x........: test9 (faultstatus.c:127)
- FAIL: expected signal 11, not 4
--- 5 ----
(Looks like new faultstatus.stderr.exp64 is needed for that last one).
Cheers,
|