|
From: Dirk M. <mu...@kd...> - 2005-07-20 21:49:03
|
SVN commit 437078 by mueller:
Handle a 'd' stab that indicates a file in pascal.
Backport from SVN-3.0 -r4220 and Fixes #89914
M +3 -2 vg_stabs.c =20
--- trunk/valgrind/coregrind/vg_stabs.c #437077:437078
@@ -727,8 +727,9 @@
}
=20
case 'k': /* const */
- case 'B': { /* volatile */
- /* ('k' | 'B') TYPE */
+ case 'B': /* volatile */
+ case 'd': { /* file (pascal only) */
+ /* ('k' | 'B' | 'd' ) TYPE */
type =3D stabtype_parser(si, NULL, &p);
break;
}
|
|
From: Dirk M. <mu...@kd...> - 2005-07-27 06:56:16
|
SVN commit 439112 by mueller:
fix compilation
M +4 -4 vg_stabs.c =20
--- trunk/valgrind/coregrind/vg_stabs.c #439111:439112
@@ -311,7 +311,7 @@
return &sf->types[sym];
}
=20
-static Bool isdigit(Char c, Int base, Int *vp)
+static Bool isdigit_base(Char c, Int base, Int *vp)
{
Bool ret =3D False;
Int v =3D 0;
@@ -382,7 +382,7 @@
if (base =3D=3D 0)
base =3D getbase(&p);
=20
- while(isdigit(*p, base, &v)) {
+ while(isdigit_base(*p, base, &v)) {
ret *=3D base;
ret +=3D v;
p++;
@@ -403,7 +403,7 @@
if (base =3D=3D 0)
base =3D getbase(&p);
=20
- while(isdigit(*p, base, &v)) {
+ while(isdigit_base(*p, base, &v)) {
ret *=3D base;
ret +=3D v;
p++;
@@ -646,7 +646,7 @@
case -27: type =3D VG_(st_mkint)(def, 1, True); break;
case -28: type =3D VG_(st_mkint)(def, 2, True); break;
case -29: type =3D VG_(st_mkint)(def, 4, True); break;
- case -30: type =3D ML_(st_mkint)(def, 2, False); break;
+ case -30: type =3D VG_(st_mkint)(def, 2, False); break;
case -31: type =3D VG_(st_mkint)(def, 8, True); break;
case -32: type =3D VG_(st_mkint)(def, 8, False); break;
case -33: type =3D VG_(st_mkint)(def, 8, False); break;
|
|
From: Josef W. <Jos...@gm...> - 2003-10-30 10:02:01
|
Hi,
I just checked my skin with Valgrind CVS and Suse 9.0,
and now I have the problem that the skin doesn't generate
dumps any more.
I have in SK_(post_clo_init):
...
VG_(sprintf)(filename, "%s.%d", dump_file_base, VG_(getpid)());
fd = VG_(open)(filename, VKI_O_WRONLY|VKI_O_TRUNC, 0);
if (-1 == fd) {
fd = VG_(open)(filename, VKI_O_CREAT|VKI_O_WRONLY,
VKI_S_IRUSR|VKI_S_IWUSR);
if (-1 == fd) {
file_err();
}
}
VG_(close)(fd);
...
to truncate/create the dump file.
With strace, I see this for this part of code:
getpid() = 13270
open("/home/weidendo/dumps/cachegrind.out.13270", O_WRONLY|O_TRUNC) = -1
ENOENT
(No such file or directory)
close(-2) = -1 EBADF (Bad file descriptor)
Obviously, strace correctly gives back -1 for
fd = VG_(open)(filename, VKI_O_WRONLY|VKI_O_TRUNC, 0);
but my skin gets -2 (Ok, that's a small bug to call close(-2), but still...).
But it should get -1, too ?!?
Josef
|
|
From: Jeremy F. <je...@go...> - 2003-10-30 10:25:37
|
On Thu, 2003-10-30 at 02:01, Josef Weidendorfer wrote:
> I just checked my skin with Valgrind CVS and Suse 9.0,
> and now I have the problem that the skin doesn't generate
> dumps any more.
Sorry, I changed the return code for VG_(open)() so it returns -ve error
code (errno) rather than simply -1. You can either use "if (fd < 0)" or
maybe something like "if (fd == -VKI_EEXIST) { ... } else { ... }".
> getpid() = 13270
> open("/home/weidendo/dumps/cachegrind.out.13270", O_WRONLY|O_TRUNC) = -1 ENOENT (No such file or directory)
> close(-2) = -1 EBADF (Bad file descriptor)
>
> Obviously, strace correctly gives back -1 for
> fd = VG_(open)(filename, VKI_O_WRONLY|VKI_O_TRUNC, 0);
> but my skin gets -2 (Ok, that's a small bug to call close(-2), but still...).
> But it should get -1, too ?!?
No. strace is (somewhat) lying - the syscall is returning -2, not -1.
If you were using libc, then open() would return -1 and set errno to 2
(ENOENT). But since we're going straight to the kernel and don't have
errno, VG_(open) is directly returning the negative error code (-2 ==
ENOENT).
J
|
|
From: Nicholas N. <nj...@ca...> - 2003-10-30 10:35:36
|
On Thu, 30 Oct 2003, Jeremy Fitzhardinge wrote: > No. strace is (somewhat) lying - the syscall is returning -2, not -1. > If you were using libc, then open() would return -1 and set errno to 2 > (ENOENT). But since we're going straight to the kernel and don't have > errno, VG_(open) is directly returning the negative error code (-2 == > ENOENT). The different views of syscalls -- glibc's view vs. the kernel's view -- has tripped me up before. Generally, the kernel returns a negative error value, and then glibc puts that in errno (but positive), and returns -1 from the call. There are some cases where the kernel vs. glibc difference is bigger -- I think mmap, brk and getcwd are examples. N |
|
From: Josef W. <Jos...@gm...> - 2003-10-30 12:31:10
|
Ok. I have no problem with this semantic change of return codes (libc vs. kernel). But this is a source incompatible change in the skin API. Can we raise the skin major version for it? Josef On Thursday 30 October 2003 11:35, Nicholas Nethercote wrote: > On Thu, 30 Oct 2003, Jeremy Fitzhardinge wrote: > > No. strace is (somewhat) lying - the syscall is returning -2, not -1. > > If you were using libc, then open() would return -1 and set errno to 2 > > (ENOENT). But since we're going straight to the kernel and don't have > > errno, VG_(open) is directly returning the negative error code (-2 == > > ENOENT). > > The different views of syscalls -- glibc's view vs. the kernel's view -- > has tripped me up before. Generally, the kernel returns a negative error > value, and then glibc puts that in errno (but positive), and returns -1 > from the call. There are some cases where the kernel vs. glibc difference > is bigger -- I think mmap, brk and getcwd are examples. > > N > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Nicholas N. <nj...@ca...> - 2003-10-30 12:37:47
|
On Thu, 30 Oct 2003, Josef Weidendorfer wrote: > I have no problem with this semantic change of return codes > (libc vs. kernel). But this is a source incompatible change in the > skin API. Can we raise the skin major version for it? Done. I think it makes sense to change the major version number only once between each "release". Eg., if a release is made, and then two, separate, incompatible changes are made before the next release, only change the version number once. Thus external skins would be targetted to match official "releases" (by "release" I guess that means any time Julian puts up a new tarball on the website). Does this seem reasonable? N |
|
From: Josef W. <Jos...@gm...> - 2003-10-30 13:00:05
|
On Thursday 30 October 2003 13:37, Nicholas Nethercote wrote: > On Thu, 30 Oct 2003, Josef Weidendorfer wrote: > > I have no problem with this semantic change of return codes > > (libc vs. kernel). But this is a source incompatible change in the > > skin API. Can we raise the skin major version for it? > > Done. > > I think it makes sense to change the major version number only once > between each "release". Eg., if a release is made, and then two, > separate, incompatible changes are made before the next release, only > change the version number once. Thus external skins would be targetted to > match official "releases" (by "release" I guess that means any time Julian > puts up a new tarball on the website). Does this seem reasonable? Of course. I almost added something like this to the last mail. If somebody is using VG CVS, he's always on his own. Josef |