|
From: Joseph T. <tu...@gm...> - 2004-06-16 13:20:14
|
I cannot build valgrind, neither version 2.0.0 nor 2.1.1, using gcc-3.3.3-r6 The error message I receive is: error: can't find a register in class `BREG' while reloading `asm' For all the details, as well as a proposed solution, please see <a href="http://bugs.gentoo.org/show_bug.cgi?id=54068">Gentoo Bug #54068</a> Thanks, Joseph -- http://www.cs.nyu.edu/~turian/ |
|
From: Tom H. <th...@cy...> - 2004-06-16 13:56:16
|
In message <4da...@ma...>
Joseph Turian <tu...@gm...> wrote:
> I cannot build valgrind, neither version 2.0.0 nor 2.1.1, using gcc-3.3.3-r6
>
> The error message I receive is:
> error: can't find a register in class `BREG' while reloading `asm'
>
> For all the details, as well as a proposed solution, please see <a
> href="http://bugs.gentoo.org/show_bug.cgi?id=54068">Gentoo Bug
> #54068</a>
Except that whoever provided that "solution" clearly hadn't looked
at the code in question as the asm call that is triggering the problem
doesn't even have a clobber list! It only has input and output lists.
A discussion of this error as it relates to valgrind can be found on
the appropriate entry in the valgrind bug tracker at:
http://bugs.kde.org/show_bug.cgi?id=79696
One thing I don't understand is why only the Gentoo build of gcc 3.3
seems to have this problem. I'm using 3.3.3 on my Fedora Core 2 box
and I don't see this at all.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Joseph T. <tu...@gm...> - 2004-06-16 16:29:48
|
> Except that whoever provided that "solution" clearly hadn't looked > at the code in question as the asm call that is triggering the problem > doesn't even have a clobber list! It only has input and output lists. Tom, It was I who provided "that 'solution'". I did not then (nor not even now) understand the intricacies of mixing C and ASM, but I thought that the time I spent on Google could only help those more knowledgable than I. I should point out that the gentoo bug-report now contains another comment, which you may (or may not) find informative. I sure don't. ;^) > A discussion of this error as it relates to valgrind can be found on > the appropriate entry in the valgrind bug tracker at: > http://bugs.kde.org/show_bug.cgi?id=79696 Thank you for the pointer. With this patch, vg_to_ucode.c compiles. How can I verify that this function works as desired (or, at the very least, sanity check it)? > Well given that I can"t reproduce the problem I was waiting for > somebody to confirm that it worked first... I ran a 'make -k' and there's but one other instance of this error: cg_main.c: In function `Intel_cache_info': cg_main.c:1163: error: can't find a register in class `BREG' while reloading `asm' If you could provide a patch for this function, I'll let you know if it works. > One thing I don't understand is why only the Gentoo build of gcc 3.3 > seems to have this problem. I'm using 3.3.3 on my Fedora Core 2 box > and I don't see this at all. Gentoo applies a number of patches to the vanilla source before building gcc. One of these probably accounts for the discrepancy. Joseph -- http://www.cs.nyu.edu/~turian/ |
|
From: Tom H. <th...@cy...> - 2004-06-16 17:30:19
|
In message <4da...@ma...>
Joseph Turian <tu...@gm...> wrote:
> > A discussion of this error as it relates to valgrind can be found on
> > the appropriate entry in the valgrind bug tracker at:
> > http://bugs.kde.org/show_bug.cgi?id=79696
>
> Thank you for the pointer. With this patch, vg_to_ucode.c compiles.
> How can I verify that this function works as desired (or, at the very
> least, sanity check it)?
Run something that looks at the CPU ID under valgrind - x86info for
example. I did in fact do that with that patch in place so it should
work. The only question was whether it would solve the problem.
> > Well given that I can"t reproduce the problem I was waiting for
> > somebody to confirm that it worked first...
>
> I ran a 'make -k' and there's but one other instance of this error:
>
> cg_main.c: In function `Intel_cache_info':
> cg_main.c:1163: error: can't find a register in class `BREG' while
> reloading `asm'
>
> If you could provide a patch for this function, I'll let you know if it
> works.
I thought that might happen. It will need a very similar fix so I will
try and sort that out in a minute.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Joseph T. <tu...@gm...> - 2004-06-16 17:37:07
|
Tom,
> Run something that looks at the CPU ID under valgrind - x86info for
> example. I did in fact do that with that patch in place so it should
> work. The only question was whether it would solve the problem.
How would I do this?
Please bear with me, I've never actually used valgrind :^}
> I thought that might happen. It will need a very similar fix so I will
> try and sort that out in a minute.
I'm standing by.
Joseph
--
http://www.cs.nyu.edu/~turian/
|
|
From: Tom H. <th...@cy...> - 2004-06-16 18:25:25
|
In message <4da...@ma...>
Joseph Turian <tu...@gm...> wrote:
> > Run something that looks at the CPU ID under valgrind - x86info for
> > example. I did in fact do that with that patch in place so it should
> > work. The only question was whether it would solve the problem.
>
> How would I do this?
> Please bear with me, I've never actually used valgrind :^}
Something like this:
valgrind --tool=none x86info -a
That should print details of your processor. If you want to test
the cachgrind fix then this:
valgrind --tool=cachegrind -v x86info
Will do - it should print a description of the cache that matches
what x86info reports.
> > I thought that might happen. It will need a very similar fix so I will
> > try and sort that out in a minute.
>
> I'm standing by.
There's a new patch on the bug now - you need to run autogen.sh and
configure after applying it.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Joseph T. <tu...@gm...> - 2004-06-16 19:36:26
|
Tom,
Awesome! It compiles just fine now.
> valgrind --tool=none x86info -a
Okay, this gives the same output, regardless of whether valgrind is used or not.
> valgrind --tool=cachegrind -v x86info
This command gives the following cache information:
--22378-- warning: Pentium with 12 K micro-op instruction trace cache
--22378-- Simulating a 16 KB cache with 32 B lines
==22378== Cache configuration used:
==22378== I1: 16384B, 8-way, 32B lines
==22378== D1: 8192B, 4-way, 64B lines
==22378== L2: 524288B, 8-way, 64B lines
x86info -a gives the following cache information:
Instruction TLB: 4K, 2MB or 4MB pages, fully associative, 128 entries.
Data TLB: 4KB or 4MB pages, fully associative, 64 entries.
L1 Data cache:
Size: 8KB Sectored, 4-way associative.
line size=64 bytes.
No L3 cache
Instruction trace cache:
Size: 12K uOps 8-way associative.
L2 unified cache:
Size: 512KB Sectored, 8-way associative.
line size=64 bytes.
> Will do - it should print a description of the cache that matches
> what x86info reports.
It appears to me that the above match.
> There's a new patch on the bug now - you need to run autogen.sh and
> configure after applying it.
There's no autogen.sh in the valgrind-2.1.1 distribution, so I just
ran aclocal && automake.
Joseph
--
http://www.cs.nyu.edu/~turian/
|
|
From: Tom H. <th...@cy...> - 2004-06-16 20:55:01
|
In message <4da...@ma...>
Joseph Turian <tu...@gm...> wrote:
> Awesome! It compiles just fine now.
Excellent. I've committed that fix. Thanks for your help.
> > There's a new patch on the bug now - you need to run autogen.sh and
> > configure after applying it.
>
> There's no autogen.sh in the valgrind-2.1.1 distribution, so I just
> ran aclocal && automake.
That's fine. It's only in CVS because the generated files are
included in the release tarballs.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Joseph T. <tu...@gm...> - 2004-06-26 19:19:49
|
Tom, I wanted to pass on a comment from the Gentoo bug report: "On another note it would be nice to get all of the trampolines resolved in valgrind as well." (http://bugs.gentoo.org/show_bug.cgi?id=54068#c5) Not sure what is meant by this, but maybe you do. Does this pertain to the error messages in the recent "Valgrind and GCC 3.4" email on this list? Because I am getting them too. Joseph On Wed, 16 Jun 2004 21:54:15 +0100, Tom Hughes <th...@cy...> wrote: > > In message <4da...@ma...> > Joseph Turian <tu...@gm...> wrote: > > > Awesome! It compiles just fine now. > > Excellent. I've committed that fix. Thanks for your help. > > > > There's a new patch on the bug now - you need to run autogen.sh and > > > configure after applying it. > > > > There's no autogen.sh in the valgrind-2.1.1 distribution, so I just > > ran aclocal && automake. > > That's fine. It's only in CVS because the generated files are > included in the release tarballs. > > > > Tom > > -- > Tom Hughes (th...@cy...) > Software Engineer, Cyberscience Corporation > http://www.cyberscience.com/ > > ------------------------------------------------------- > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- http://www.cs.nyu.edu/~turian/ |
|
From: Tom H. <th...@cy...> - 2004-06-26 20:20:11
|
In message <4da...@ma...>
Joseph Turian <tu...@gm...> wrote:
> I wanted to pass on a comment from the Gentoo bug report:
> "On another note it would be nice to get all of the trampolines
> resolved in valgrind as well."
> (http://bugs.gentoo.org/show_bug.cgi?id=54068#c5)
>
> Not sure what is meant by this, but maybe you do.
I have no idea what it means... Perhaps you could find out?
The only thing I can think they're talking about is the issue with
nested functions in gcc, which cause trampolines to be built on the
stack that valgrind can't handle.
We are aware of that but don't have a good fix at the moment. Using
nested functions is horrible anyway and I guess that NX support is
going to put a stop to it because the stack won't be executable.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-06-16 14:21:09
|
On Wed, 16 Jun 2004, Tom Hughes wrote: > A discussion of this error as it relates to valgrind can be found on > the appropriate entry in the valgrind bug tracker at: > > http://bugs.kde.org/show_bug.cgi?id=79696 Should it be committed? N |
|
From: Tom H. <th...@cy...> - 2004-06-16 14:29:18
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Wed, 16 Jun 2004, Tom Hughes wrote:
>
>> A discussion of this error as it relates to valgrind can be found on
>> the appropriate entry in the valgrind bug tracker at:
>>
>> http://bugs.kde.org/show_bug.cgi?id=79696
>
> Should it be committed?
Well given that I can't reproduce the problem I was waiting for
somebody to confirm that it worked first...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Sergey V. <vs...@al...> - 2004-06-29 10:17:08
|
On Sat, 26 Jun 2004 21:20:40 +0100 Tom Hughes wrote: > The only thing I can think they're talking about is the issue with > nested functions in gcc, which cause trampolines to be built on the > stack that valgrind can't handle. > > We are aware of that but don't have a good fix at the moment. Using > nested functions is horrible anyway and I guess that NX support is > going to put a stop to it because the stack won't be executable. Unfortunately, it won't. When GCC generates trampolines, it puts a special flag into the object file, which is then propagated to the ELF headers and signals the ELF loader to make stack executable. So the programs which use trampolines will use them as before, but will run without the stack protection. |