Re: Valgrind: Detect access outside the range of malloc.
From: Otto Moerbeek Date: Tue, 17 Oct 2023 10:54:17 +0200 > On Tue, Oct 17, 2023 at 05:41:06PM +0900, Masato Asou wrote: > >> From: Otto Moerbeek >> Date: Tue, 17 Oct 2023 07:52:12 +0200 >> >> > On Tue, Oct 17, 2023 at 07:33:47AM +0900, Masato Asou wrote: >> > >> >> From: Masato Asou >> >> Date: Fri, 29 Sep 2023 19:39:12 +0900 (JST) >> >> >> >> ping >> > >> > Sorry for not replying earlier. >> >> No problem :-) >> >> > The locations are reported >> > correctly now. But there are spurious reports of accesses of a 8 byte >> > value on each system call. (tested on amd64). >> > >> >-Otto >> > >> > ==83949== Use of uninitialised value of size 8 >> > ==83949==at 0x4A0CEC2: write (sys/w_write.c:28) >> > ==83949==by 0x4A1B322: __sflush (stdio/fflush.c:80) >> > ==83949==by 0x49B21E8: __sfvwrite (stdio/fvwrite.c:188) >> > ==83949==by 0x4A26FED: __sprint (stdio/vfprintf.c:108) >> > ==83949==by 0x4A26FED: __vfprintf (stdio/vfprintf.c:1062) >> > ==83949==by 0x4A23CA5: vfprintf (stdio/vfprintf.c:263) >> > ==83949==by 0x49EDB54: printf (stdio/printf.c:44) >> > ==83949==by 0x109B90: main (m.c:16) >> >> I know this issue. This is due to the references to the FS (F >> segment) registers TCB and TIB made by ENTER_CANCEL_POINT and >> LEAVE_CANCEL_POINT during the system call invocation. >> >> I think this problem should be solved in the `.supp' files (valgrind >> --suppressions=). I am working on a `.supp' file for >> OpenBSD. However, this cannot be created quickly yet. Wouldn't it be >> better to commit the `.supp' file as a separate modification? > > Yes, a separate commit is fine. Would this suppression file end up in > pkg-readmes, or does valgrind have a place to store a system-wide > default supression file? > > -Otto Probably, if I write DEFAULT_SUPP="$srcdir/openbsd.supp" in configure.ac, it will be installed in /usr/local/libexec/valgrind/default.supp. -- ASOU Masato >> -- >> ASOU Masato >> >> >> >> >> > I have fixed the bug you reported when symbols were not printed. >> >> > >> >> > As shown below, if the lower 12 bits of Virtual Address are 0 and File >> >> > Size is 0, then the a.out symbol will not be printed. >> >> > >> >> > $ readelf -l a.out >> >> > >> >> > Program Headers: >> >> > Type Offset VirtAddr PhysAddr >> >> > FileSizMemSiz Flags Align >> >> > >> >> > LOAD 0x1000 0x3000 >> >> > 0x3000 >> >> > 0x 0x0055 RW 1000 >> >> > >> >> > From: Otto Moerbeek >> >> > Date: Tue, 5 Sep 2023 07:40:18 +0200 >> >> > >> >> >> On Tue, Sep 05, 2023 at 09:38:40AM +0900, Masato Asou wrote: >> >> >> >> >> >>> hi, >> >> >>> >> >> >>> I have fixed a bug in Valgrind. The Valgrind could not detect access >> >> >>> outside the range of malloc. >> >> >>> >> >> >>> comments, ok? >> >> >> >> >> >> This works much better that before. Thanks for working on this! >> >> >> >> >> >> It now detects out of bounds read and writes correctly. A double >> >> >> free is detected. >> >> >> Also, the spurious reports for accesses to errno are gone. >> >> >> >> >> >> It does not report proper locations though, even if I compile my test >> >> >> program with -g: >> >> >> >> >> >> ==23912== Invalid read of size 1 >> >> >> ==23912==at 0x109B5D: ??? (in ./a.out) >> >> >> ==23912==by 0x1098D1: ??? (in ./a.out) >> >> >> ==23912== Address 0x4a42840 is 0 bytes after a block of size 10,240 >> >> >> alloc'd >> >> >> ==23912==at 0x493A3A9: malloc (vg_replace_malloc.c:435) >> >> >> ==23912==by 0x109B32: ??? (in ./a.out) >> >> >> ==23912==by 0x1098D1: ??? (in ./a.out) >> >> >> ==23912== >> >> >> 0 >> >> > >> >&g
Re: Valgrind: Detect access outside the range of malloc.
From: Otto Moerbeek
Date: Tue, 17 Oct 2023 07:52:12 +0200
> On Tue, Oct 17, 2023 at 07:33:47AM +0900, Masato Asou wrote:
>
>> From: Masato Asou
>> Date: Fri, 29 Sep 2023 19:39:12 +0900 (JST)
>>
>> ping
>
> Sorry for not replying earlier.
No problem :-)
> The locations are reported
> correctly now. But there are spurious reports of accesses of a 8 byte
> value on each system call. (tested on amd64).
>
> -Otto
>
> ==83949== Use of uninitialised value of size 8
> ==83949==at 0x4A0CEC2: write (sys/w_write.c:28)
> ==83949==by 0x4A1B322: __sflush (stdio/fflush.c:80)
> ==83949==by 0x49B21E8: __sfvwrite (stdio/fvwrite.c:188)
> ==83949==by 0x4A26FED: __sprint (stdio/vfprintf.c:108)
> ==83949==by 0x4A26FED: __vfprintf (stdio/vfprintf.c:1062)
> ==83949==by 0x4A23CA5: vfprintf (stdio/vfprintf.c:263)
> ==83949==by 0x49EDB54: printf (stdio/printf.c:44)
> ==83949==by 0x109B90: main (m.c:16)
I know this issue. This is due to the references to the FS (F
segment) registers TCB and TIB made by ENTER_CANCEL_POINT and
LEAVE_CANCEL_POINT during the system call invocation.
I think this problem should be solved in the `.supp' files (valgrind
--suppressions=). I am working on a `.supp' file for
OpenBSD. However, this cannot be created quickly yet. Wouldn't it be
better to commit the `.supp' file as a separate modification?
--
ASOU Masato
>>
>> > I have fixed the bug you reported when symbols were not printed.
>> >
>> > As shown below, if the lower 12 bits of Virtual Address are 0 and File
>> > Size is 0, then the a.out symbol will not be printed.
>> >
>> > $ readelf -l a.out
>> >
>> > Program Headers:
>> > Type Offset VirtAddr PhysAddr
>> > FileSizMemSiz Flags Align
>> >
>> > LOAD 0x1000 0x3000 0x3000
>> > 0x 0x0055 RW 1000
>> >
>> > From: Otto Moerbeek
>> > Date: Tue, 5 Sep 2023 07:40:18 +0200
>> >
>> >> On Tue, Sep 05, 2023 at 09:38:40AM +0900, Masato Asou wrote:
>> >>
>> >>> hi,
>> >>>
>> >>> I have fixed a bug in Valgrind. The Valgrind could not detect access
>> >>> outside the range of malloc.
>> >>>
>> >>> comments, ok?
>> >>
>> >> This works much better that before. Thanks for working on this!
>> >>
>> >> It now detects out of bounds read and writes correctly. A double
>> >> free is detected.
>> >> Also, the spurious reports for accesses to errno are gone.
>> >>
>> >> It does not report proper locations though, even if I compile my test
>> >> program with -g:
>> >>
>> >> ==23912== Invalid read of size 1
>> >> ==23912==at 0x109B5D: ??? (in ./a.out)
>> >> ==23912==by 0x1098D1: ??? (in ./a.out)
>> >> ==23912== Address 0x4a42840 is 0 bytes after a block of size 10,240
>> >> alloc'd
>> >> ==23912==at 0x493A3A9: malloc (vg_replace_malloc.c:435)
>> >> ==23912==by 0x109B32: ??? (in ./a.out)
>> >> ==23912==by 0x1098D1: ??? (in ./a.out)
>> >> ==23912==
>> >> 0
>> >
>> > The a.out symbol is now printed as shown below:
>> >
>> > $ cat malloctest.c
>> > #include
>> > #include
>> >
>> > int
>> > main(int argc, char *argv[])
>> > {
>> >size_t sz = atoi(argv[1]);
>> >unsigned char *p = malloc(sz);
>> >printf("%p\n", p);
>> >p[sz] = 0;
>> >printf("%x\n", p[sz]);
>> >free(p);
>> >free(p);
>> >return 0;
>> > }
>> > $ cc -g malloctest.c
>> > $ valgrind ./a.out 128
>> > ==21074== Memcheck, a memory error detector
>> > ==21074== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
>> > ==21074== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright
>> > info
>> > ==21074== Command: ./a.out 128
>> > ==21074==
>> > ==21074== Use of uninitialised value of size 8
>> > ==21074==at 0x49C34CD: write (sys/w_write.c:26)
>> > ==21074==by 0x4A150D2: __sflush (stdio/fflush.c:80)
>> > ==21074==by 0x49B99C8: __sfvwrite (stdio/fvwrite.c:191)
>> > ==21074==by 0x4979E4D: __sprint (stdio/vfprintf.c:108)
>> > ==21074==by
Re: Valgrind: Detect access outside the range of malloc.
From: Masato Asou
Date: Fri, 29 Sep 2023 19:39:12 +0900 (JST)
ping
> I have fixed the bug you reported when symbols were not printed.
>
> As shown below, if the lower 12 bits of Virtual Address are 0 and File
> Size is 0, then the a.out symbol will not be printed.
>
> $ readelf -l a.out
>
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSizMemSiz Flags Align
>
> LOAD 0x1000 0x3000 0x3000
> 0x 0x0055 RW 1000
>
> From: Otto Moerbeek
> Date: Tue, 5 Sep 2023 07:40:18 +0200
>
>> On Tue, Sep 05, 2023 at 09:38:40AM +0900, Masato Asou wrote:
>>
>>> hi,
>>>
>>> I have fixed a bug in Valgrind. The Valgrind could not detect access
>>> outside the range of malloc.
>>>
>>> comments, ok?
>>
>> This works much better that before. Thanks for working on this!
>>
>> It now detects out of bounds read and writes correctly. A double
>> free is detected.
>> Also, the spurious reports for accesses to errno are gone.
>>
>> It does not report proper locations though, even if I compile my test
>> program with -g:
>>
>> ==23912== Invalid read of size 1
>> ==23912==at 0x109B5D: ??? (in ./a.out)
>> ==23912==by 0x1098D1: ??? (in ./a.out)
>> ==23912== Address 0x4a42840 is 0 bytes after a block of size 10,240 alloc'd
>> ==23912==at 0x493A3A9: malloc (vg_replace_malloc.c:435)
>> ==23912==by 0x109B32: ??? (in ./a.out)
>> ==23912==by 0x1098D1: ??? (in ./a.out)
>> ==23912==
>> 0
>
> The a.out symbol is now printed as shown below:
>
> $ cat malloctest.c
> #include
> #include
>
> int
> main(int argc, char *argv[])
> {
> size_t sz = atoi(argv[1]);
> unsigned char *p = malloc(sz);
> printf("%p\n", p);
> p[sz] = 0;
> printf("%x\n", p[sz]);
> free(p);
> free(p);
> return 0;
> }
> $ cc -g malloctest.c
> $ valgrind ./a.out 128
> ==21074== Memcheck, a memory error detector
> ==21074== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
> ==21074== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
> ==21074== Command: ./a.out 128
> ==21074==
> ==21074== Use of uninitialised value of size 8
> ==21074==at 0x49C34CD: write (sys/w_write.c:26)
> ==21074==by 0x4A150D2: __sflush (stdio/fflush.c:80)
> ==21074==by 0x49B99C8: __sfvwrite (stdio/fvwrite.c:191)
> ==21074==by 0x4979E4D: __sprint (stdio/vfprintf.c:108)
> ==21074==by 0x4979E4D: __vfprintf (stdio/vfprintf.c:1064)
> ==21074==by 0x4976B05: vfprintf (stdio/vfprintf.c:263)
> ==21074==by 0x49D6434: printf (stdio/printf.c:44)
> ==21074==by 0x109B48: main (malloctest.c:9)
> ==21074==
> ==21074== Use of uninitialised value of size 8
> ==21074==at 0x49C34DE: write (sys/w_write.c:26)
> ==21074==by 0x4A150D2: __sflush (stdio/fflush.c:80)
> ==21074==by 0x49B99C8: __sfvwrite (stdio/fvwrite.c:191)
> ==21074==by 0x4979E4D: __sprint (stdio/vfprintf.c:108)
> ==21074==by 0x4979E4D: __vfprintf (stdio/vfprintf.c:1064)
> ==21074==by 0x4976B05: vfprintf (stdio/vfprintf.c:263)
> ==21074==by 0x49D6434: printf (stdio/printf.c:44)
> ==21074==by 0x109B48: main (malloctest.c:9)
>
>> ==23912== Invalid free() / delete / delete[] / realloc()
>> ==23912==at 0x493C981: free (vg_replace_malloc.c:978)
>> ==23912==by 0x109B80: ??? (in ./a.out)
>> ==23912==by 0x1098D1: ??? (in ./a.out)
>> ==23912== Address 0x4a40040 is 0 bytes inside a block of size 10,240 free'd
>> ==23912==at 0x493C981: free (vg_replace_malloc.c:978)
>> ==23912==by 0x109B77: ??? (in ./a.out)
>> ==23912==by 0x1098D1: ??? (in ./a.out)
>> ==23912== Block was alloc'd at
>> ==23912==at 0x493A3A9: malloc (vg_replace_malloc.c:435)
>> ==23912==by 0x109B32: ??? (in ./a.out)
>> ==23912==by 0x1098D1: ??? (in ./a.out)
>>
>> addr2line -e ./a.out 0x109B80 also does not succeed in translating the
>> address.
>
> Address reported by Valgrind cannot be used for addr2line. Because
> the address is the address of the area where Valgrind mapped a.out
> with mmap().
>
>
> The Makefile and patch-coregrind_m_replacemalloc_vg_replace_malloc_c
> in the following diff are the same as the first reported diff.
>
> ok, comments?
> --
> ASOU Masato
>
> Index: devel/valgrind/Makefile
> ===
> RCS file: /c
Re: Valgrind: Detect access outside the range of malloc.
I have fixed the bug you reported when symbols were not printed.
As shown below, if the lower 12 bits of Virtual Address are 0 and File
Size is 0, then the a.out symbol will not be printed.
$ readelf -l a.out
Program Headers:
Type Offset VirtAddr PhysAddr
FileSizMemSiz Flags Align
LOAD 0x1000 0x3000 0x3000
0x 0x0055 RW 1000
From: Otto Moerbeek
Date: Tue, 5 Sep 2023 07:40:18 +0200
> On Tue, Sep 05, 2023 at 09:38:40AM +0900, Masato Asou wrote:
>
>> hi,
>>
>> I have fixed a bug in Valgrind. The Valgrind could not detect access
>> outside the range of malloc.
>>
>> comments, ok?
>
> This works much better that before. Thanks for working on this!
>
> It now detects out of bounds read and writes correctly. A double
> free is detected.
> Also, the spurious reports for accesses to errno are gone.
>
> It does not report proper locations though, even if I compile my test
> program with -g:
>
> ==23912== Invalid read of size 1
> ==23912==at 0x109B5D: ??? (in ./a.out)
> ==23912==by 0x1098D1: ??? (in ./a.out)
> ==23912== Address 0x4a42840 is 0 bytes after a block of size 10,240 alloc'd
> ==23912==at 0x493A3A9: malloc (vg_replace_malloc.c:435)
> ==23912==by 0x109B32: ??? (in ./a.out)
> ==23912==by 0x1098D1: ??? (in ./a.out)
> ==23912==
> 0
The a.out symbol is now printed as shown below:
$ cat malloctest.c
#include
#include
int
main(int argc, char *argv[])
{
size_t sz = atoi(argv[1]);
unsigned char *p = malloc(sz);
printf("%p\n", p);
p[sz] = 0;
printf("%x\n", p[sz]);
free(p);
free(p);
return 0;
}
$ cc -g malloctest.c
$ valgrind ./a.out 128
==21074== Memcheck, a memory error detector
==21074== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==21074== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==21074== Command: ./a.out 128
==21074==
==21074== Use of uninitialised value of size 8
==21074==at 0x49C34CD: write (sys/w_write.c:26)
==21074==by 0x4A150D2: __sflush (stdio/fflush.c:80)
==21074==by 0x49B99C8: __sfvwrite (stdio/fvwrite.c:191)
==21074==by 0x4979E4D: __sprint (stdio/vfprintf.c:108)
==21074==by 0x4979E4D: __vfprintf (stdio/vfprintf.c:1064)
==21074==by 0x4976B05: vfprintf (stdio/vfprintf.c:263)
==21074==by 0x49D6434: printf (stdio/printf.c:44)
==21074==by 0x109B48: main (malloctest.c:9)
==21074==
==21074== Use of uninitialised value of size 8
==21074==at 0x49C34DE: write (sys/w_write.c:26)
==21074==by 0x4A150D2: __sflush (stdio/fflush.c:80)
==21074==by 0x49B99C8: __sfvwrite (stdio/fvwrite.c:191)
==21074==by 0x4979E4D: __sprint (stdio/vfprintf.c:108)
==21074==by 0x4979E4D: __vfprintf (stdio/vfprintf.c:1064)
==21074==by 0x4976B05: vfprintf (stdio/vfprintf.c:263)
==21074==by 0x49D6434: printf (stdio/printf.c:44)
==21074==by 0x109B48: main (malloctest.c:9)
> ==23912== Invalid free() / delete / delete[] / realloc()
> ==23912==at 0x493C981: free (vg_replace_malloc.c:978)
> ==23912==by 0x109B80: ??? (in ./a.out)
> ==23912==by 0x1098D1: ??? (in ./a.out)
> ==23912== Address 0x4a40040 is 0 bytes inside a block of size 10,240 free'd
> ==23912==at 0x493C981: free (vg_replace_malloc.c:978)
> ==23912==by 0x109B77: ??? (in ./a.out)
> ==23912==by 0x1098D1: ??? (in ./a.out)
> ==23912== Block was alloc'd at
> ==23912==at 0x493A3A9: malloc (vg_replace_malloc.c:435)
> ==23912==by 0x109B32: ??? (in ./a.out)
> ==23912==by 0x1098D1: ??? (in ./a.out)
>
> addr2line -e ./a.out 0x109B80 also does not succeed in translating the
> address.
Address reported by Valgrind cannot be used for addr2line. Because
the address is the address of the area where Valgrind mapped a.out
with mmap().
The Makefile and patch-coregrind_m_replacemalloc_vg_replace_malloc_c
in the following diff are the same as the first reported diff.
ok, comments?
--
ASOU Masato
Index: devel/valgrind/Makefile
===
RCS file: /cvs/ports/devel/valgrind/Makefile,v
retrieving revision 1.32
diff -u -p -r1.32 Makefile
--- devel/valgrind/Makefile 21 Sep 2023 09:50:07 - 1.32
+++ devel/valgrind/Makefile 29 Sep 2023 09:44:46 -
@@ -5,7 +5,7 @@ CATEGORIES =devel
V =3.21.0
DISTNAME = valgrind-${V}
-REVISION = 0
+REVISION = 1
EXTRACT_SUFX = .tar.bz2
SITES =https://sourceware.org/pub/valgrind/
Index: devel/valgrind/patches/patch-coregrind_m_aspacemgr_aspacemgr_linux_c
===
Re: Valgrind: Detect access outside the range of malloc.
From: Otto Moerbeek
Date: Tue, 5 Sep 2023 07:40:18 +0200
> On Tue, Sep 05, 2023 at 09:38:40AM +0900, Masato Asou wrote:
>
>> hi,
>>
>> I have fixed a bug in Valgrind. The Valgrind could not detect access
>> outside the range of malloc.
>>
>> comments, ok?
>
> This works much better that before. Thanks for working on this!
>
> It now detects out of bounds read and writes correctly. A double
> free is detected.
> Also, the spurious reports for accesses to errno are gone.
Thank you for your comment.
> It does not report proper locations though, even if I compile my test
> program with -g:
Could you show me your test program?
--
ASOU Masato
> ==23912== Invalid read of size 1
> ==23912==at 0x109B5D: ??? (in ./a.out)
> ==23912==by 0x1098D1: ??? (in ./a.out)
> ==23912== Address 0x4a42840 is 0 bytes after a block of size 10,240 alloc'd
> ==23912==at 0x493A3A9: malloc (vg_replace_malloc.c:435)
> ==23912==by 0x109B32: ??? (in ./a.out)
> ==23912==by 0x1098D1: ??? (in ./a.out)
> ==23912==
> 0
> ==23912== Invalid free() / delete / delete[] / realloc()
> ==23912==at 0x493C981: free (vg_replace_malloc.c:978)
> ==23912==by 0x109B80: ??? (in ./a.out)
> ==23912==by 0x1098D1: ??? (in ./a.out)
> ==23912== Address 0x4a40040 is 0 bytes inside a block of size 10,240 free'd
> ==23912==at 0x493C981: free (vg_replace_malloc.c:978)
> ==23912==by 0x109B77: ??? (in ./a.out)
> ==23912==by 0x1098D1: ??? (in ./a.out)
> ==23912== Block was alloc'd at
> ==23912==at 0x493A3A9: malloc (vg_replace_malloc.c:435)
> ==23912==by 0x109B32: ??? (in ./a.out)
> ==23912==by 0x1098D1: ??? (in ./a.out)
>
> addr2line -e ./a.out 0x109B80 also does not succeed in translating the
> address.
>
> There are also a few spurious reports of the form:
>
> ==23912== Use of uninitialised value of size 8
> ==23912==at 0x499518D: write (sys/w_write.c:26)
> ==23912==by 0x49E9FB2: __sflush (stdio/fflush.c:80)
> ==23912==by 0x49DA548: __sfvwrite (stdio/fvwrite.c:191)
> ==23912==by 0x49E42ED: __sprint (stdio/vfprintf.c:108)
> ==23912==by 0x49E42ED: __vfprintf (stdio/vfprintf.c:1064)
> ==23912==by 0x49E0FA5: vfprintf (stdio/vfprintf.c:263)
> ==23912==by 0x49F7C74: printf (stdio/printf.c:44)
> ==23912==by 0x109B48: ??? (in ./a.out)
> ==23912==by 0x1098D1: ??? (in ./a.out)
>
> But it is a great improvement,
>
> -Otto
>
>> --
>> ASOU Masato
>>
>> Index: devel/valgrind/Makefile
>> ===
>> RCS file: /cvs/ports/devel/valgrind/Makefile,v
>> retrieving revision 1.31
>> diff -u -p -r1.31 Makefile
>> --- devel/valgrind/Makefile 5 Aug 2023 03:32:22 - 1.31
>> +++ devel/valgrind/Makefile 4 Sep 2023 23:14:33 -
>> @@ -5,7 +5,7 @@ CATEGORIES = devel
>>
>> V = 3.21.0
>> DISTNAME = valgrind-${V}
>> -REVISION = 0
>> +REVISION = 1
>> EXTRACT_SUFX = .tar.bz2
>>
>> MASTER_SITES = https://sourceware.org/pub/valgrind/
>> Index:
>> devel/valgrind/patches/patch-coregrind_m_replacemalloc_vg_replace_malloc_c
>> ===
>> RCS file:
>> devel/valgrind/patches/patch-coregrind_m_replacemalloc_vg_replace_malloc_c
>> diff -N
>> devel/valgrind/patches/patch-coregrind_m_replacemalloc_vg_replace_malloc_c
>> --- /dev/null1 Jan 1970 00:00:00 -
>> +++
>> devel/valgrind/patches/patch-coregrind_m_replacemalloc_vg_replace_malloc_c
>> 4 Sep 2023 23:14:33 -
>> @@ -0,0 +1,263 @@
>> +--- coregrind/m_replacemalloc/vg_replace_malloc.c.orig
>> coregrind/m_replacemalloc/vg_replace_malloc.c
>> +@@ -222,7 +222,7 @@
>> + #define SET_ERRNO_ENOMEM if (__errno_location)\
>> + (*__errno_location ()) = VKI_ENOMEM;
>> + #define SET_ERRNO_EINVAL {}
>> +-#elif defined(VGO_freebsd)
>> ++#elif defined(VGO_freebsd) || defined(VGO_openbsd)
>> + extern int *__error (void) __attribute__((weak));
>> + #define SET_ERRNO_ENOMEM if (__error)\
>> + (*__error ()) = VKI_ENOMEM;
>> +@@ -430,7 +430,7 @@
>> + ALLOC_or_NULL(VG_Z_LIBC_SONAME, malloc, malloc);
>> + ALLOC_or_NULL(SO_SYN_MALLOC, malloc, malloc);
>> +
>> +-#elif defined(VGO_freebsd)
>> ++#elif defined(VGO_freebsd) || defined(VGO_openbsd)
>> + ALLOC_or_NULL(VG_Z_LIBC_SONAME, malloc, malloc);
>> + ALLOC_or_NULL(SO_SYN_MALLOC, malloc, malloc);
>> +
>
Valgrind: Detect access outside the range of malloc.
hi,
I have fixed a bug in Valgrind. The Valgrind could not detect access
outside the range of malloc.
comments, ok?
--
ASOU Masato
Index: devel/valgrind/Makefile
===
RCS file: /cvs/ports/devel/valgrind/Makefile,v
retrieving revision 1.31
diff -u -p -r1.31 Makefile
--- devel/valgrind/Makefile 5 Aug 2023 03:32:22 - 1.31
+++ devel/valgrind/Makefile 4 Sep 2023 23:14:33 -
@@ -5,7 +5,7 @@ CATEGORIES =devel
V =3.21.0
DISTNAME = valgrind-${V}
-REVISION = 0
+REVISION = 1
EXTRACT_SUFX = .tar.bz2
MASTER_SITES = https://sourceware.org/pub/valgrind/
Index:
devel/valgrind/patches/patch-coregrind_m_replacemalloc_vg_replace_malloc_c
===
RCS file:
devel/valgrind/patches/patch-coregrind_m_replacemalloc_vg_replace_malloc_c
diff -N
devel/valgrind/patches/patch-coregrind_m_replacemalloc_vg_replace_malloc_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ devel/valgrind/patches/patch-coregrind_m_replacemalloc_vg_replace_malloc_c
4 Sep 2023 23:14:33 -
@@ -0,0 +1,263 @@
+--- coregrind/m_replacemalloc/vg_replace_malloc.c.orig
coregrind/m_replacemalloc/vg_replace_malloc.c
+@@ -222,7 +222,7 @@
+ #define SET_ERRNO_ENOMEM if (__errno_location)\
+ (*__errno_location ()) = VKI_ENOMEM;
+ #define SET_ERRNO_EINVAL {}
+-#elif defined(VGO_freebsd)
++#elif defined(VGO_freebsd) || defined(VGO_openbsd)
+ extern int *__error (void) __attribute__((weak));
+ #define SET_ERRNO_ENOMEM if (__error)\
+ (*__error ()) = VKI_ENOMEM;
+@@ -430,7 +430,7 @@
+ ALLOC_or_NULL(VG_Z_LIBC_SONAME, malloc, malloc);
+ ALLOC_or_NULL(SO_SYN_MALLOC, malloc, malloc);
+
+-#elif defined(VGO_freebsd)
++#elif defined(VGO_freebsd) || defined(VGO_openbsd)
+ ALLOC_or_NULL(VG_Z_LIBC_SONAME, malloc, malloc);
+ ALLOC_or_NULL(SO_SYN_MALLOC, malloc, malloc);
+
+@@ -472,7 +472,7 @@
+ ALLOC_or_BOMB(SO_SYN_MALLOC, _Znwm, __builtin_new);
+ #endif
+
+-#elif defined(VGO_freebsd)
++#elif defined(VGO_freebsd) || defined(VGO_openbsd)
+ // operator new(unsigned int)
+ #if VG_WORDSIZE == 4
+ ALLOC_or_BOMB(VG_Z_LIBSTDCXX_SONAME, _Znwj, __builtin_new);
+@@ -532,7 +532,7 @@
+ ALLOC_or_BOMB_ALIGNED(SO_SYN_MALLOC, _ZnwmSt11align_val_t,
__builtin_new_aligned);
+ #endif
+
+-#elif defined(VGO_freebsd)
++#elif defined(VGO_freebsd) || defined(VGO_openbsd)
+ // operator new(unsigned int)
+ #if VG_WORDSIZE == 4
+ ALLOC_or_BOMB_ALIGNED(VG_Z_LIBSTDCXX_SONAME, _ZnwjSt11align_val_t,
__builtin_new_aligned);
+@@ -592,7 +592,7 @@
+ ALLOC_or_NULL(SO_SYN_MALLOC, _ZnwmRKSt9nothrow_t, __builtin_new);
+ #endif
+
+-#elif defined(VGO_freebsd)
++#elif defined(VGO_freebsd) || defined(VGO_openbsd)
+ // operator new(unsigned, std::nothrow_t const&)
+ #if VG_WORDSIZE == 4
+ ALLOC_or_NULL(VG_Z_LIBSTDCXX_SONAME, _ZnwjRKSt9nothrow_t, __builtin_new);
+@@ -652,7 +652,7 @@
+ ALLOC_or_NULL_ALIGNED(SO_SYN_MALLOC,
_ZnwmSt11align_val_tRKSt9nothrow_t, __builtin_new_aligned);
+ #endif
+
+-#elif defined(VGO_freebsd)
++#elif defined(VGO_freebsd) || defined(VGO_openbsd)
+ // operator new(unsigned int, std::align_val_t, std::nothrow_t const&)
+ #if VG_WORDSIZE == 4
+ ALLOC_or_NULL_ALIGNED(VG_Z_LIBSTDCXX_SONAME,
_ZnwjSt11align_val_tRKSt9nothrow_t, __builtin_new_aligned);
+@@ -714,7 +714,7 @@
+ ALLOC_or_BOMB(SO_SYN_MALLOC, _Znam, __builtin_vec_new );
+ #endif
+
+-#elif defined(VGO_freebsd)
++#elif defined(VGO_freebsd) || defined(VGO_openbsd)
+ // operator new[](unsigned int)
+ #if VG_WORDSIZE == 4
+ ALLOC_or_BOMB(VG_Z_LIBSTDCXX_SONAME, _Znaj, __builtin_vec_new );
+@@ -774,7 +774,7 @@
+ ALLOC_or_BOMB_ALIGNED(SO_SYN_MALLOC, _ZnamSt11align_val_t,
__builtin_vec_new_aligned );
+ #endif
+
+-#elif defined(VGO_freebsd)
++#elif defined(VGO_freebsd) || defined(VGO_openbsd)
+ // operator new[](unsigned int, std::align_val_t)
+ #if VG_WORDSIZE == 4
+ ALLOC_or_BOMB_ALIGNED(VG_Z_LIBSTDCXX_SONAME, _ZnajSt11align_val_t,
__builtin_vec_new_aligned );
+@@ -835,7 +835,7 @@
+ ALLOC_or_NULL(SO_SYN_MALLOC, _ZnamRKSt9nothrow_t, __builtin_vec_new
);
+ #endif
+
+-#elif defined(VGO_freebsd)
++#elif defined(VGO_freebsd) || defined(VGO_openbsd)
+ // operator new[](unsigned, std::nothrow_t const&)
+ #if VG_WORDSIZE == 4
+ ALLOC_or_NULL(VG_Z_LIBSTDCXX_SONAME, _ZnajRKSt9nothrow_t, __builtin_vec_new
);
+@@ -895,7 +895,7 @@
+ ALLOC_or_NULL_ALIGNED(SO_SYN_MALLOC,
_ZnamSt11align_val_tRKSt9nothrow_t, __builtin_vec_new_aligned );
+ #endif
+
+-#elif defined(VGO_freebsd)
++#elif defined(VGO_freebsd) || defined(VGO_openbsd)
+ // operator new[](unsigned int, std::align_val_t, std::nothrow_t const&)
+ #if VG_WORDSIZE == 4
+ ALLOC_or_NULL_ALIGNED(VG_Z_LIBSTDCXX_SONAME,
Re: [fixbug] devel/valgrind: display symblo
From: Masato Asou
Date: Fri, 04 Aug 2023 07:57:42 +0900 (JST)
> From: Omar Polo
> Date: Thu, 03 Aug 2023 23:36:06 +0200
>
>>> > other than this, while the changes are a bit over my head, I've
>>> > quickly tested it and it seems to be working. So, fwiw, OK op@.
>>> >
>>> > I still get some ??? entries, for example with grep:
>>> >
>>> > $ make clean obj
>>> > [...]
>>> > $ make DEBUG='-O0 -g3'
>>> > [...]
>>> > $ valgrind obj/grep foo Makefile
>>> > [...]
>>> > ==31128== Use of uninitialised value of size 8
>>> > ==31128==at 0x49D935D: ??? (in obj/grep)
>>> > ==31128==by 0x10F385: grep_reallocarray (util.c:615)
>>> > ==31128==by 0x10D626: add_pattern (grep.c:186)
>>> > ==31128==by 0x10D426: add_patterns (grep.c:224)
>>> > ==31128==by 0x10D03C: main (grep.c:473)
>>> > [...]
>>>
>>> I also tried DEBUG="-O0 -g3", but ??? was not displayed. Is your
>>> libc.so stripped?
>>
>> nope. while i've rebuilt and installed it, it's not stripped. I can
>> set a breakpoint in, for e.g., reallocarray in egdb and step into libc
>> just fine.
>>
>> Not a blocker for your diff IMHO since it improves the situation.
>> Given the tricky port I guess it's better to have this in.
>
> I will investigate into it again.
I reproduced the problem in my OpenBSD and found the cause. I forget
to attach the diff of coregrind/m_options.c.
comment, ok?
--
ASOU Masato
Index: Makefile
===
RCS file: /cvs/ports/devel/valgrind/Makefile,v
retrieving revision 1.30
diff -u -p -r1.30 Makefile
--- Makefile18 Jul 2023 06:17:15 - 1.30
+++ Makefile3 Aug 2023 23:09:52 -
@@ -5,6 +5,7 @@ CATEGORIES =devel
V =3.21.0
DISTNAME = valgrind-${V}
+REVISION = 0
EXTRACT_SUFX = .tar.bz2
MASTER_SITES = https://sourceware.org/pub/valgrind/
Index: patches/patch-coregrind_m_debuginfo_debuginfo_c
===
RCS file:
/cvs/ports/devel/valgrind/patches/patch-coregrind_m_debuginfo_debuginfo_c,v
retrieving revision 1.1
diff -u -p -r1.1 patch-coregrind_m_debuginfo_debuginfo_c
--- patches/patch-coregrind_m_debuginfo_debuginfo_c 18 Jul 2023 06:17:15
- 1.1
+++ patches/patch-coregrind_m_debuginfo_debuginfo_c 3 Aug 2023 23:09:52
-
@@ -27,7 +27,17 @@
ok = ML_(read_elf_debug_info)( di );
# elif defined(VGO_darwin)
ok = ML_(read_macho_debug_info)( di );
-@@ -1347,7 +1347,7 @@
+@@ -1265,6 +1265,9 @@
+ || defined(VGA_mips64) || defined(VGA_nanomips)
+is_rx_map = seg->hasR && seg->hasX;
+is_rw_map = seg->hasR && seg->hasW;
++# elif defined(VGO_openbsd)
++ is_rx_map = seg->hasX;
++ is_rw_map = seg->hasR && seg->hasW;
+ # elif defined(VGA_amd64) || defined(VGA_ppc64be) || defined(VGA_ppc64le) \
+ || defined(VGA_arm) || defined(VGA_arm64)
+is_rx_map = seg->hasR && seg->hasX && !seg->hasW;
+@@ -1347,7 +1350,7 @@
#endif
/* We're only interested in mappings of object files. */
@@ -36,7 +46,7 @@
rw_load_count = 0;
-@@ -2408,7 +2408,7 @@
+@@ -2408,7 +2411,7 @@
VG_STREQ("generic_start_main", name) || // Yellow Dog doggedness
VG_STREQN(19, "generic_start_main.", name) || // gcc optimization
VG_STREQ("_start", name) ||
Index: patches/patch-coregrind_m_debuginfo_readelf_c
===
RCS file:
/cvs/ports/devel/valgrind/patches/patch-coregrind_m_debuginfo_readelf_c,v
retrieving revision 1.3
diff -u -p -r1.3 patch-coregrind_m_debuginfo_readelf_c
--- patches/patch-coregrind_m_debuginfo_readelf_c 18 Jul 2023 06:17:15
- 1.3
+++ patches/patch-coregrind_m_debuginfo_readelf_c 3 Aug 2023 23:09:52
-
@@ -30,7 +30,26 @@
res = VG_(do_syscall3)(__NR_readlink, (UWord)path, (UWord)buf, bufsiz);
#elif defined(VGO_solaris)
res = VG_(do_syscall4)(__NR_readlinkat, VKI_AT_FDCWD, (UWord)path,
-@@ -2654,7 +2658,8 @@
+@@ -2141,6 +2145,18 @@
+i, (UWord)item.bias);
+ loaded = True;
+ }
++#if defined(VGO_openbsd)
++ if (map->rx
++ && (a_phdr.p_flags & (PF_X))
++== (PF_X)) {
++item.exec = True;
++VG_(addToXA)(svma_ranges, );
++TRACE_SYMTAB(
++ "PT_LOAD[%ld]: acqu
Re: [fixbug] devel/valgrind: display symblo
From: Omar Polo Date: Thu, 03 Aug 2023 23:36:06 +0200 >> > other than this, while the changes are a bit over my head, I've >> > quickly tested it and it seems to be working. So, fwiw, OK op@. >> > >> > I still get some ??? entries, for example with grep: >> > >> >$ make clean obj >> >[...] >> >$ make DEBUG='-O0 -g3' >> >[...] >> >$ valgrind obj/grep foo Makefile >> >[...] >> >==31128== Use of uninitialised value of size 8 >> >==31128==at 0x49D935D: ??? (in obj/grep) >> >==31128==by 0x10F385: grep_reallocarray (util.c:615) >> >==31128==by 0x10D626: add_pattern (grep.c:186) >> >==31128==by 0x10D426: add_patterns (grep.c:224) >> >==31128==by 0x10D03C: main (grep.c:473) >> >[...] >> >> I also tried DEBUG="-O0 -g3", but ??? was not displayed. Is your >> libc.so stripped? > > nope. while i've rebuilt and installed it, it's not stripped. I can > set a breakpoint in, for e.g., reallocarray in egdb and step into libc > just fine. > > Not a blocker for your diff IMHO since it improves the situation. > Given the tricky port I guess it's better to have this in. I will investigate into it again. Thank you. -- ASOU Masato
Re: [fixbug] devel/valgrind: display symblo
From: Omar Polo
Date: Thu, 03 Aug 2023 10:52:56 +0200
> On 2023/08/03 16:11:46 +0900, Masato Asou wrote:
>> Hi,
>>
>> I have solved the problem of Valgrind not displaying function names
>> and file names when it detects a problem.
>>
>> [...]
>>
>> comments, ok?
>
> it's missing a REVISION bump in the Makefile since the content of the
> package changes.
I forget a REVISION bump. Append following change.
diff -u -p -r1.30 Makefile
--- Makefile18 Jul 2023 06:17:15 - 1.30
+++ Makefile3 Aug 2023 20:29:59 -
@@ -5,6 +5,7 @@ CATEGORIES =devel
V =3.21.0
DISTNAME = valgrind-${V}
+REVISION = 0
EXTRACT_SUFX = .tar.bz2
MASTER_SITES = https://sourceware.org/pub/valgrind/
> other than this, while the changes are a bit over my head, I've
> quickly tested it and it seems to be working. So, fwiw, OK op@.
>
> I still get some ??? entries, for example with grep:
>
> $ make clean obj
> [...]
> $ make DEBUG='-O0 -g3'
> [...]
> $ valgrind obj/grep foo Makefile
> [...]
> ==31128== Use of uninitialised value of size 8
> ==31128==at 0x49D935D: ??? (in obj/grep)
> ==31128==by 0x10F385: grep_reallocarray (util.c:615)
> ==31128==by 0x10D626: add_pattern (grep.c:186)
> ==31128==by 0x10D426: add_patterns (grep.c:224)
> ==31128==by 0x10D03C: main (grep.c:473)
> [...]
I also tried DEBUG="-O0 -g3", but ??? was not displayed. Is your
libc.so stripped?
> but it's already so much better :-)
Thank you. I will commit.
--
ASOU Masato
[fixbug] devel/valgrind: display symblo
Hi,
I have solved the problem of Valgrind not displaying function names
and file names when it detects a problem.
Could not display symbols with current Valgrind as below:
$ cd /usr/src/usr.bin/grep
$ make COPTS="-g
cc -O2 -pipe -Wall -g -MD -MP -c /usr/src/usr.bin/grep/binary.c
cc -O2 -pipe -Wall -g -MD -MP -c /usr/src/usr.bin/grep/file.c
cc -O2 -pipe -Wall -g -MD -MP -c /usr/src/usr.bin/grep/grep.c
cc -O2 -pipe -Wall -g -MD -MP -c /usr/src/usr.bin/grep/mmfile.c
cc -O2 -pipe -Wall -g -MD -MP -c /usr/src/usr.bin/grep/queue.c
cc -O2 -pipe -Wall -g -MD -MP -c /usr/src/usr.bin/grep/util.c
cc -o grep binary.o file.o grep.o mmfile.o queue.o util.o -lz
$ valgrind obj/grep PATH /etc/skel/.profile
==67899== Memcheck, a memory error detector
==67899== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==67899== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==67899== Command: obj/grep PATH /etc/skel/.profile
==67899==
==67899== Use of uninitialised value of size 8
==67899==at 0x49AD34D: ??? (in obj/grep)
==67899==by 0x10EF2A: ??? (in obj/grep)
==67899==by 0x10CDFF: ??? (in obj/grep)
==67899==by 0x10CB02: ??? (in obj/grep)
==67899==by 0x10B821: ??? (in obj/grep)
And applied following patch as below:
$ cd /usr/src/usr.bin/grep
$ make COPTS="-g"
cc -O2 -pipe -Wall -g -MD -MP -c /usr/src/usr.bin/grep/binary.c
cc -O2 -pipe -Wall -g -MD -MP -c /usr/src/usr.bin/grep/file.c
cc -O2 -pipe -Wall -g -MD -MP -c /usr/src/usr.bin/grep/grep.c
cc -O2 -pipe -Wall -g -MD -MP -c /usr/src/usr.bin/grep/mmfile.c
cc -O2 -pipe -Wall -g -MD -MP -c /usr/src/usr.bin/grep/queue.c
cc -O2 -pipe -Wall -g -MD -MP -c /usr/src/usr.bin/grep/util.c
cc -o grep binary.o file.o grep.o mmfile.o queue.o util.o -lz
$ valgrind obj/grep PATH /etc/skel/.profile
==78943== Memcheck, a memory error detector
==78943== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==78943== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==78943== Command: obj/grep PATH /etc/skel/.profile
==78943==
==78943== Use of uninitialised value of size 8
==78943==at 0x49D9B0D: realloc (stdlib/malloc.c:1897)
==78943==by 0x10EF2A: grep_reallocarray (util.c:615)
==78943==by 0x10CDFF: add_pattern (grep.c:186)
==78943==by 0x10CB02: add_patterns (grep.c:224)
==78943==by 0x10CB02: main (grep.c:473)
comments, ok?
--
ASOU Masato
? devel/valgrind/old-patches
? devel/valgrind/patches/patch-coregrind_m_options_c
Index: devel/valgrind/patches/patch-coregrind_m_debuginfo_debuginfo_c
===
RCS file:
/cvs/ports/devel/valgrind/patches/patch-coregrind_m_debuginfo_debuginfo_c,v
retrieving revision 1.1
diff -u -p -r1.1 patch-coregrind_m_debuginfo_debuginfo_c
--- devel/valgrind/patches/patch-coregrind_m_debuginfo_debuginfo_c 18 Jul
2023 06:17:15 - 1.1
+++ devel/valgrind/patches/patch-coregrind_m_debuginfo_debuginfo_c 3 Aug
2023 06:52:29 -
@@ -27,7 +27,17 @@
ok = ML_(read_elf_debug_info)( di );
# elif defined(VGO_darwin)
ok = ML_(read_macho_debug_info)( di );
-@@ -1347,7 +1347,7 @@
+@@ -1265,6 +1265,9 @@
+ || defined(VGA_mips64) || defined(VGA_nanomips)
+is_rx_map = seg->hasR && seg->hasX;
+is_rw_map = seg->hasR && seg->hasW;
++# elif defined(VGO_openbsd)
++ is_rx_map = seg->hasX;
++ is_rw_map = seg->hasR && seg->hasW;
+ # elif defined(VGA_amd64) || defined(VGA_ppc64be) || defined(VGA_ppc64le) \
+ || defined(VGA_arm) || defined(VGA_arm64)
+is_rx_map = seg->hasR && seg->hasX && !seg->hasW;
+@@ -1347,7 +1350,7 @@
#endif
/* We're only interested in mappings of object files. */
@@ -36,7 +46,7 @@
rw_load_count = 0;
-@@ -2408,7 +2408,7 @@
+@@ -2408,7 +2411,7 @@
VG_STREQ("generic_start_main", name) || // Yellow Dog doggedness
VG_STREQN(19, "generic_start_main.", name) || // gcc optimization
VG_STREQ("_start", name) ||
Index: devel/valgrind/patches/patch-coregrind_m_debuginfo_readelf_c
===
RCS file:
/cvs/ports/devel/valgrind/patches/patch-coregrind_m_debuginfo_readelf_c,v
retrieving revision 1.3
diff -u -p -r1.3 patch-coregrind_m_debuginfo_readelf_c
--- devel/valgrind/patches/patch-coregrind_m_debuginfo_readelf_c18 Jul
2023 06:17:15 - 1.3
+++ devel/valgrind/patches/patch-coregrind_m_debuginfo_readelf_c3 Aug
2023 06:52:29 -
@@ -30,7 +30,26 @@
res =
Re: valgrind: mark broken
From: Theo Buehler Date: Sat, 8 Oct 2022 11:46:36 +0200 > There are still a few syscall numbers that are missing or not quite > right. I'll need a bit of time to think about the rest of your diff. > > --- vki-scnums-openbsd.h Sat Oct 8 11:32:14 2022 > +++ syscall.h Sat Oct 8 11:46:11 2022 Currently, valgrind exits immediately after launch. This is due to the following commit. I am working on a solution to this, but it will take some time. commit 8db818c7f40fac08bddec07697f8f4afe76dcbaa Author: deraadt Date: Sat Oct 8 16:58:34 2022 + The signal trampoline and timekeep regions can be marked immutable at execve() time ok kettenis diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c index 761441cd2dd..af474ee7d8d 100644 --- a/sys/kern/kern_exec.c +++ b/sys/kern/kern_exec.c @@ -1,4 +1,4 @@ -/* $OpenBSD: kern_exec.c,v 1.232 2022/10/07 14:59:39 deraadt Exp $ */ +/* $OpenBSD: kern_exec.c,v 1.233 2022/10/08 16:58:34 deraadt Exp $ */ /* $NetBSD: kern_exec.c,v 1.75 1996/02/09 18:59:28 christos Exp $ */ /*- @@ -863,6 +863,8 @@ exec_sigcode_map(struct process *pr) uao_detach(sigobject); return (ENOMEM); } + uvm_map_immutable(>ps_vmspace->vm_map, pr->ps_sigcode, + pr->ps_sigcode + round_page(sz), 1, "sig"); /* Calculate PC at point of sigreturn entry */ pr->ps_sigcoderet = pr->ps_sigcode + (sigcoderet - sigcode); @@ -911,6 +913,8 @@ exec_timekeep_map(struct process *pr) uao_detach(timekeep_object); return (ENOMEM); } + uvm_map_immutable(>ps_vmspace->vm_map, pr->ps_timekeep, + pr->ps_timekeep + timekeep_sz, 1, "time"); return (0); } -- ASOU Masato
Re: valgrind: mark broken
From: Stefan Sperling
Date: Fri, 7 Oct 2022 10:27:47 +0200
> On Fri, Oct 07, 2022 at 02:37:15PM +0900, Masato Asou wrote:
>> Hi tb and ports,
>>
>> I have adapted the system call number definition to the new syscall.h
>>
>> comments, ok?
>
> Thank you!
>
> I have tried running devel/got in valgrind and it fails because
> the __realpath syscall is missing. Could this be fixed?
>
> --59025-- WARNING: unhandled syscall: 115
> --59025-- You may be able to write your own handler.
> --59025-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
>
> In sys/kern/syscalls.master:
>
> 115 STD { int sys___realpath(const char *pathname, \
> char *resolved); }
>
I was fixed above problem.
New diff is below:
Index: Makefile
===
RCS file: /cvs/ports/devel/valgrind/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- Makefile3 Sep 2022 09:42:46 - 1.29
+++ Makefile8 Oct 2022 06:32:29 -
@@ -1,4 +1,3 @@
-BROKEN = syscall table and wrappers need to be updated to
reflect reality
ONLY_FOR_ARCHS = amd64
COMMENT = instrumentation framework for dynamic analysis tools
@@ -6,7 +5,7 @@ CATEGORIES =devel
V =3.10.1
PV = 20160331
-REVISION = 20
+REVISION = 21
DISTNAME = valgrind-${V}
EXTRACT_SUFX = .tar.bz2
Index: patches/patch-coregrind_m_aspacemgr_aspacemgr-common_c
===
RCS file:
/cvs/ports/devel/valgrind/patches/patch-coregrind_m_aspacemgr_aspacemgr-common_c,v
retrieving revision 1.1
diff -u -p -r1.1 patch-coregrind_m_aspacemgr_aspacemgr-common_c
--- patches/patch-coregrind_m_aspacemgr_aspacemgr-common_c 2 Oct 2019
17:19:29 - 1.1
+++ patches/patch-coregrind_m_aspacemgr_aspacemgr-common_c 8 Oct 2022
06:32:29 -
@@ -1,5 +1,16 @@
--- coregrind/m_aspacemgr/aspacemgr-common.c.orig
+++ coregrind/m_aspacemgr/aspacemgr-common.c
+@@ -187,8 +187,8 @@
+ # elif defined(VGP_amd64_openbsd)
+if (flags & VKI_MAP_ANONYMOUS && fd == 0)
+ fd = -1;
+- res = VG_(do_syscall7)(__NR_mmap, (UWord)start, length,
+-prot, flags, fd, 0, offset);
++ res = VG_(do_syscall6)(__NR_mmap, (UWord)start, length,
++prot, flags, fd, offset);
+ # else
+ #error Unknown platform
+ # endif
@@ -458,7 +458,11 @@ VgStack* VG_(am_alloc_VgStack)( /*OUT*/Addr* initial_sp )
szB = VG_STACK_GUARD_SZB
+ VG_STACK_ACTIVE_SZB + VG_STACK_GUARD_SZB;
Index: patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h
===
RCS file:
/cvs/ports/devel/valgrind/patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h,v
retrieving revision 1.2
diff -u -p -r1.2 patch-coregrind_m_syswrap_priv_syswrap_openbsd_h
--- patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h23 Dec 2019
23:26:32 - 1.2
+++ patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h8 Oct 2022
06:32:29 -
@@ -1,19 +1,66 @@
--- coregrind/m_syswrap/priv_syswrap-openbsd.h.orig
+++ coregrind/m_syswrap/priv_syswrap-openbsd.h
-@@ -50,7 +50,7 @@
- DECL_TEMPLATE(openbsd, sys_open);
- DECL_TEMPLATE(openbsd, sys_close);
- DECL_TEMPLATE(openbsd, sys_getentropy);
--DECL_TEMPLATE(openbsd, sys___tfork);
-+DECL_TEMPLATE(openbsd, sys___tfork_thread);
- DECL_TEMPLATE(openbsd, sys_link);
- DECL_TEMPLATE(openbsd, sys_unlink);
- DECL_TEMPLATE(openbsd, sys_wait4);
-@@ -144,6 +144,7 @@
+@@ -80,7 +80,7 @@
+ DECL_TEMPLATE(openbsd, sys_chflagsat);
+ DECL_TEMPLATE(openbsd, sys_fchflags);
+ DECL_TEMPLATE(openbsd, sys_sync);
+-DECL_TEMPLATE(openbsd, sys_kill);
++DECL_TEMPLATE(openbsd, sys_msyscall);
+ DECL_TEMPLATE(openbsd, sys_getppid);
+ DECL_TEMPLATE(openbsd, sys_dup);
+ DECL_TEMPLATE(openbsd, sys_dup3);
+@@ -93,7 +93,7 @@
+ DECL_TEMPLATE(openbsd, sys_sigprocmask);
+ DECL_TEMPLATE(openbsd, sys_sigtimedwait);
+ DECL_TEMPLATE(openbsd, sys_sigwaitinfo);
+-DECL_TEMPLATE(openbsd, sys_getlogin);
++DECL_TEMPLATE(openbsd, sys_getlogin_r);
+ DECL_TEMPLATE(openbsd, sys_setlogin);
+ DECL_TEMPLATE(openbsd, sys_acct);
+ DECL_TEMPLATE(openbsd, sys_sigpending);
+@@ -118,7 +118,6 @@
+ DECL_TEMPLATE(openbsd, sys_munmap);
+ DECL_TEMPLATE(openbsd, sys_mprotect);
+ DECL_TEMPLATE(openbsd, sys_madvise);
+-DECL_TEMPLATE(openbsd, sys_mincore);
+ DECL_TEMPLATE(openbsd, sys_getgroups);
+ DECL_TEMPLATE(openbsd, sys_setgroups);
+ DECL_TEMPLATE(openbsd, sys_getpgrp);
+@@ -144,12 +143,15 @@
DECL_TEMPLATE(openbsd, sys_pledge);
DECL_TEMPLATE(openbsd, sys_ppoll);
DECL_TEMPLATE(openbsd, sys_pselect);
+DECL_TEMPLATE(openbsd, sys_unveil);
++DECL_TEMPLATE(openbsd, sys___realpath);
DECL_TEMPLATE(openbsd, sys_sigsuspend);
DECL_TEMPLATE(op
Re: valgrind: mark broken
From: Stefan Sperling
Date: Fri, 7 Oct 2022 10:27:47 +0200
> On Fri, Oct 07, 2022 at 02:37:15PM +0900, Masato Asou wrote:
>> Hi tb and ports,
>>
>> I have adapted the system call number definition to the new syscall.h
>>
>> comments, ok?
>
> Thank you!
>
> I have tried running devel/got in valgrind and it fails because
> the __realpath syscall is missing. Could this be fixed?
>
> --59025-- WARNING: unhandled syscall: 115
> --59025-- You may be able to write your own handler.
> --59025-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
>
> In sys/kern/syscalls.master:
>
> 115 STD { int sys___realpath(const char *pathname, \
> char *resolved); }
>
Thank for your bug report.
I have reproduced problem using the realpath command. I am
investigating.
--
ASOU Masato
Re: valgrind: mark broken
Hi tb and ports,
I have adapted the system call number definition to the new syscall.h
comments, ok?
Index: Makefile
===
RCS file: /cvs/ports/devel/valgrind/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- Makefile3 Sep 2022 09:42:46 - 1.29
+++ Makefile7 Oct 2022 05:31:46 -
@@ -1,4 +1,3 @@
-BROKEN = syscall table and wrappers need to be updated to
reflect reality
ONLY_FOR_ARCHS = amd64
COMMENT = instrumentation framework for dynamic analysis tools
@@ -6,7 +5,7 @@ CATEGORIES =devel
V =3.10.1
PV = 20160331
-REVISION = 20
+REVISION = 21
DISTNAME = valgrind-${V}
EXTRACT_SUFX = .tar.bz2
Index: patches/patch-coregrind_m_aspacemgr_aspacemgr-common_c
===
RCS file:
/cvs/ports/devel/valgrind/patches/patch-coregrind_m_aspacemgr_aspacemgr-common_c,v
retrieving revision 1.1
diff -u -p -r1.1 patch-coregrind_m_aspacemgr_aspacemgr-common_c
--- patches/patch-coregrind_m_aspacemgr_aspacemgr-common_c 2 Oct 2019
17:19:29 - 1.1
+++ patches/patch-coregrind_m_aspacemgr_aspacemgr-common_c 7 Oct 2022
05:31:46 -
@@ -1,5 +1,16 @@
--- coregrind/m_aspacemgr/aspacemgr-common.c.orig
+++ coregrind/m_aspacemgr/aspacemgr-common.c
+@@ -187,8 +187,8 @@
+ # elif defined(VGP_amd64_openbsd)
+if (flags & VKI_MAP_ANONYMOUS && fd == 0)
+ fd = -1;
+- res = VG_(do_syscall7)(__NR_mmap, (UWord)start, length,
+-prot, flags, fd, 0, offset);
++ res = VG_(do_syscall6)(__NR_mmap, (UWord)start, length,
++prot, flags, fd, offset);
+ # else
+ #error Unknown platform
+ # endif
@@ -458,7 +458,11 @@ VgStack* VG_(am_alloc_VgStack)( /*OUT*/Addr* initial_sp )
szB = VG_STACK_GUARD_SZB
+ VG_STACK_ACTIVE_SZB + VG_STACK_GUARD_SZB;
Index: patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h
===
RCS file:
/cvs/ports/devel/valgrind/patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h,v
retrieving revision 1.2
diff -u -p -r1.2 patch-coregrind_m_syswrap_priv_syswrap_openbsd_h
--- patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h23 Dec 2019
23:26:32 - 1.2
+++ patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h7 Oct 2022
05:31:46 -
@@ -1,19 +1,58 @@
--- coregrind/m_syswrap/priv_syswrap-openbsd.h.orig
+++ coregrind/m_syswrap/priv_syswrap-openbsd.h
-@@ -50,7 +50,7 @@
- DECL_TEMPLATE(openbsd, sys_open);
- DECL_TEMPLATE(openbsd, sys_close);
- DECL_TEMPLATE(openbsd, sys_getentropy);
--DECL_TEMPLATE(openbsd, sys___tfork);
-+DECL_TEMPLATE(openbsd, sys___tfork_thread);
- DECL_TEMPLATE(openbsd, sys_link);
- DECL_TEMPLATE(openbsd, sys_unlink);
- DECL_TEMPLATE(openbsd, sys_wait4);
-@@ -144,6 +144,7 @@
- DECL_TEMPLATE(openbsd, sys_pledge);
- DECL_TEMPLATE(openbsd, sys_ppoll);
- DECL_TEMPLATE(openbsd, sys_pselect);
-+DECL_TEMPLATE(openbsd, sys_unveil);
- DECL_TEMPLATE(openbsd, sys_sigsuspend);
- DECL_TEMPLATE(openbsd, sys_gettimeofday);
- DECL_TEMPLATE(openbsd, sys_getrusage);
+@@ -80,7 +80,7 @@
+ DECL_TEMPLATE(openbsd, sys_chflagsat);
+ DECL_TEMPLATE(openbsd, sys_fchflags);
+ DECL_TEMPLATE(openbsd, sys_sync);
+-DECL_TEMPLATE(openbsd, sys_kill);
++DECL_TEMPLATE(openbsd, sys_msyscall);
+ DECL_TEMPLATE(openbsd, sys_getppid);
+ DECL_TEMPLATE(openbsd, sys_dup);
+ DECL_TEMPLATE(openbsd, sys_dup3);
+@@ -93,7 +93,7 @@
+ DECL_TEMPLATE(openbsd, sys_sigprocmask);
+ DECL_TEMPLATE(openbsd, sys_sigtimedwait);
+ DECL_TEMPLATE(openbsd, sys_sigwaitinfo);
+-DECL_TEMPLATE(openbsd, sys_getlogin);
++DECL_TEMPLATE(openbsd, sys_getlogin_r);
+ DECL_TEMPLATE(openbsd, sys_setlogin);
+ DECL_TEMPLATE(openbsd, sys_acct);
+ DECL_TEMPLATE(openbsd, sys_sigpending);
+@@ -118,7 +118,6 @@
+ DECL_TEMPLATE(openbsd, sys_munmap);
+ DECL_TEMPLATE(openbsd, sys_mprotect);
+ DECL_TEMPLATE(openbsd, sys_madvise);
+-DECL_TEMPLATE(openbsd, sys_mincore);
+ DECL_TEMPLATE(openbsd, sys_getgroups);
+ DECL_TEMPLATE(openbsd, sys_setgroups);
+ DECL_TEMPLATE(openbsd, sys_getpgrp);
+@@ -151,6 +150,7 @@
+ DECL_TEMPLATE(openbsd, sys_getsockopt);
+ DECL_TEMPLATE(openbsd, sys_readv);
+ DECL_TEMPLATE(openbsd, sys_writev);
++DECL_TEMPLATE(openbsd, sys_kill);
+ DECL_TEMPLATE(openbsd, sys_settimeofday);
+ DECL_TEMPLATE(openbsd, sys_fchown);
+ DECL_TEMPLATE(openbsd, sys_fchmod);
+@@ -168,12 +168,12 @@
+ DECL_TEMPLATE(openbsd, sys_adjtime);
+ DECL_TEMPLATE(openbsd, sys_setsid);
+ DECL_TEMPLATE(openbsd, sys_quotactl);
++DECL_TEMPLATE(openbsd, sys_ypconnect);
+ DECL_TEMPLATE(openbsd, sys_nfssvc);
+ DECL_TEMPLATE(openbsd, sys_getdomainname);
+ DECL_TEMPLATE(openbsd, sys_setdomainname);
+ DECL_TEMPLATE(openbsd, sys_getfh);
+ DECL_TEMPLATE(openbsd, sys_sysarch);
+-DECL_TEMPLATE(openbsd, sys_pread);
+ DECL_TEMPLATE(openbsd,
Re: [PATCH] fix valgrind abort
Hi Andrew,
From: Andrew Hewus Fresh
Date: Wed, 24 Mar 2021 19:02:54 -0700
> On Thu, Mar 25, 2021 at 09:50:17AM +0900, Masato Asou wrote:
>> Because, Perl 5.32.1 has changed the way hexadecimal string are
>> handled as below:
>>
>> Perl 5.30.3: "0x1234" + 0x1000 -> 0x2234
>> Perl 5.32.1: "0x1234" + 0x1000 -> 0x1000
>
> Interestingly, this bug only existed in perl v5.30, so an unfortunate
> accident of timing on the creation of this patch.
>
> $ perldoc perl5320delta | grep -B4 134230
>• Perl no longer treats strings starting with "0x" or "0b" as hex or
>binary numbers respectively when converting a string to a number.
>This reverts a change in behaviour inadvertently introduced in perl
>5.30.0 intended to improve precision when converting a string to a
>floating point number. [perl #134230
><https://rt.perl.org/Ticket/Display.html?id=134230>]
>
>
>> Perl 5.32.1 does not consider anything after 'x' to be a number, but
>> only the first '0' is consider to be a number.
>
> Neither does any other perl 5, only perl 5.30 accidentally did.
>
> Perl simplistically looks for leading ascii digits in in a string to
> "convert" from a string to a number, and an empty string is treated as
> 0. Just because the unquoted version would be treated differently
> isn't supposed to matter.
>
> $ perl -E 'say "$_: " . ( "${_}x123" + 0 ) for qw< 0 1 987 a z >'
> 0: 0
> 1: 1
> 987: 987
> a: 0
> z: 0
Thank you for your detailed explanation.
>> I made the following patch.
>>
>> ok? comments?
>> --
>> ASOU Masato
>>
>> Index: devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in
>> ===
>> RCS file:
>> /cvs/ports/devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in,v
>> retrieving revision 1.5
>> diff -u -p -r1.5 patch-coregrind_link_tool_exe_openbsd_in
>> --- devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in 5
>> Oct 2020 01:45:58 - 1.5
>> +++ devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in 25
>> Mar 2021 00:27:19 -
>> @@ -10,7 +10,7 @@
>> +# strip command rewrite offset and align in ELF file. Therefor, when
>> valgrind
>> +# launch memcheck-amd64-openbsd, an Abort trap occurs in the execvp()
>> system
>> +# call.
>> -+my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-Ttext=0x%x",
>> "$ala + 0x1000";
>> ++my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-Ttext=0x%x",
>> hex($ala) + 0x1000;
>
> This seems to give consistent results on all the perl I have from 5.8
> through 5.33.7.
>
> perl -e 'my $ala = "0x1234"; print(( $ala + 0x100 ), "\n"); print(( hex($ala)
> + 0x100 ), "\n")'
>
> OK afresh1@
commited.
--
ASOU Masato
[PATCH] fix valgrind abort
Hi ports, The valgrind was aborted after updated Pert to 5.32.1 as below: $ sysctl -n kern.version OpenBSD 6.9-beta (GENERIC.MP) #428: Wed Mar 24 11:12:16 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP $ /usr/bin/perl --version This is perl 5, version 32, subversion 1 (v5.32.1) built for amd64-openbsd $ cd /usr/ports/devel/valgrind $ doas make install $ valgrind /bin/ls Abort trap $ Because, Perl 5.32.1 has changed the way hexadecimal string are handled as below: Perl 5.30.3: "0x1234" + 0x1000 -> 0x2234 Perl 5.32.1: "0x1234" + 0x1000 -> 0x1000 Perl 5.32.1 does not consider anything after 'x' to be a number, but only the first '0' is consider to be a number. I made the following patch. ok? comments? -- ASOU Masato Index: devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in === RCS file: /cvs/ports/devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in,v retrieving revision 1.5 diff -u -p -r1.5 patch-coregrind_link_tool_exe_openbsd_in --- devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in 5 Oct 2020 01:45:58 - 1.5 +++ devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in 25 Mar 2021 00:27:19 - @@ -10,7 +10,7 @@ +# strip command rewrite offset and align in ELF file. Therefor, when valgrind +# launch memcheck-amd64-openbsd, an Abort trap occurs in the execvp() system +# call. -+my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-Ttext=0x%x", "$ala + 0x1000"; ++my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-Ttext=0x%x", hex($ala) + 0x1000; -# so, build up the complete command here: -# 'cc' -static -Ttext='ala' 'restargs'
Re: valgrind
From: Otto Moerbeek
Subject: Re: valgrind
Date: Wed, 16 Dec 2020 20:27:58 +0100
> On Wed, Dec 16, 2020 at 09:33:43AM +0100, Otto Moerbeek wrote:
>
>> On Mon, Dec 14, 2020 at 02:24:52PM +0900, Masato Asou wrote:
>>
>> > Hi,
>> >
>> > From: Otto Moerbeek
>> > Date: Fri, 11 Dec 2020 08:54:36 +0100
>> >
>> > > Hi,
>> > >
>> > > I did some basic testing of valgrind on amd64 and it seems to be in
>> > > better shape than before, at least for memory leak detection.
>> > >
>> > > But I do seem to get a report on every syscall done. One example:
>> > >
>> > > ==7218== Use of uninitialised value of size 8
>> > > ==7218==at 0x4A7670E: write (sys/w_write.c:28)
>> > > ==7218==by 0x4A40F52: __sflush (stdio/fflush.c:80)
>> > > ==7218==by 0x4A94726: __sfvwrite (stdio/fvwrite.c:191)
>> > > ==7218==by 0x4ACCA68: __sprint (stdio/vfprintf.c:111)
>> > > ==7218==by 0x4ACCA68: __vfprintf (stdio/vfprintf.c:1107)
>> > > ==7218==by 0x4AC8851: vfprintf (stdio/vfprintf.c:266)
>> > > ==7218==by 0x4A7C8A0: printf (stdio/printf.c:44)
>> > > ==7218==by 0x109AB8: main (x.c:14)
>> > >
>> > > Is there a way to avoid this? If so, it would be nice to mention that
>> > > in a pkg-readme.
>> > >
>> > > -Otto
>> >
>> > Do you want somethig like this?
>>
>> Thanks, that looks nice, but first I think it is good if I do an
>> investigation *why* this is reported.
>
> As far as I can see, the error is reported every time the value
> returned by TIB_GET() is used. In the case of write(2) that is via
> the ENTER_CANCEL_POINT and LEAVE_CANCEL_POINT macros.
Yes, this error seems to occur with the reference to the TIB retrieved
by TIB_GET().
>
> I have no clue how to fix this yet.
In order to suppress this error, we have to make TIB references not be
an error in Valgrind. We need more time.
By the way, uebayasi has been left developper team. Maybe your first
email did not reached uebayasi.
--
ASOU Masato
>
>
>>
>> -Otto
>>
>> >
>> > $ cvs -q diff .
>> > Index: devel/valgrind/pkg-readme
>> > ===
>> > RCS file: devel/valgrind/pkg-readme
>> > diff -N devel/valgrind/pkg-readme
>> > --- /dev/null 1 Jan 1970 00:00:00 -
>> > +++ devel/valgrind/pkg-readme 14 Dec 2020 05:18:59 -
>> > @@ -0,0 +1,23 @@
>> > +Suppressiong errors
>> > +
>> > +If you got a report on every syscall done as followes:
>> > +
>> > +==67551== Use of uninitialised value of size 8
>> > +==67551==at 0x4AC08F9: write (sys/w_write.c:26)
>> > +==67551==by 0x4A5AC12: __sflush (stdio/fflush.c:80)
>> > +==67551==by 0x4A4C676: __sfvwrite (stdio/fvwrite.c:191)
>> > +==67551==by 0x4A80CD8: __sprint (stdio/vfprintf.c:111)
>> > +==67551==by 0x4A80CD8: __vfprintf (stdio/vfprintf.c:1107)
>> > +==67551==by 0x4A7CAC1: vfprintf (stdio/vfprintf.c:266)
>> > +==67551==by 0x4A54680: printf (stdio/printf.c:44)
>> > +==67551==by 0x109BA5: main (main.c:19)
>> > +
>> > +You can use --gen-suppressions=yes and --suppressions=FILENAME
>> > options of
>> > +valgrind.
>> > +
>> > +$ yes | valgrind --gen-suppressions=yes ./a.out 2>supress.txt
>> > +$ sed -e '/^==.*[^{]$/d' -e 's/==.*{/{/' supress.log >
>> > supress.txt
>> > +$ valgrind --suppressions=supress.txt ./a.out
>> > +
>> > +See also:
>> > +https://www.valgrind.org/docs/manual/manual-core.html#manual-core.suppress
>> > --
>> > ASOU Masato
>>
Re: valgrind
Hi,
From: Otto Moerbeek
Date: Fri, 11 Dec 2020 08:54:36 +0100
> Hi,
>
> I did some basic testing of valgrind on amd64 and it seems to be in
> better shape than before, at least for memory leak detection.
>
> But I do seem to get a report on every syscall done. One example:
>
> ==7218== Use of uninitialised value of size 8
> ==7218==at 0x4A7670E: write (sys/w_write.c:28)
> ==7218==by 0x4A40F52: __sflush (stdio/fflush.c:80)
> ==7218==by 0x4A94726: __sfvwrite (stdio/fvwrite.c:191)
> ==7218==by 0x4ACCA68: __sprint (stdio/vfprintf.c:111)
> ==7218==by 0x4ACCA68: __vfprintf (stdio/vfprintf.c:1107)
> ==7218==by 0x4AC8851: vfprintf (stdio/vfprintf.c:266)
> ==7218==by 0x4A7C8A0: printf (stdio/printf.c:44)
> ==7218==by 0x109AB8: main (x.c:14)
>
> Is there a way to avoid this? If so, it would be nice to mention that
> in a pkg-readme.
>
> -Otto
Do you want somethig like this?
$ cvs -q diff .
Index: devel/valgrind/pkg-readme
===
RCS file: devel/valgrind/pkg-readme
diff -N devel/valgrind/pkg-readme
--- /dev/null 1 Jan 1970 00:00:00 -
+++ devel/valgrind/pkg-readme 14 Dec 2020 05:18:59 -
@@ -0,0 +1,23 @@
+Suppressiong errors
+
+If you got a report on every syscall done as followes:
+
+==67551== Use of uninitialised value of size 8
+==67551==at 0x4AC08F9: write (sys/w_write.c:26)
+==67551==by 0x4A5AC12: __sflush (stdio/fflush.c:80)
+==67551==by 0x4A4C676: __sfvwrite (stdio/fvwrite.c:191)
+==67551==by 0x4A80CD8: __sprint (stdio/vfprintf.c:111)
+==67551==by 0x4A80CD8: __vfprintf (stdio/vfprintf.c:1107)
+==67551==by 0x4A7CAC1: vfprintf (stdio/vfprintf.c:266)
+==67551==by 0x4A54680: printf (stdio/printf.c:44)
+==67551==by 0x109BA5: main (main.c:19)
+
+You can use --gen-suppressions=yes and --suppressions=FILENAME
options of
+valgrind.
+
+$ yes | valgrind --gen-suppressions=yes ./a.out 2>supress.txt
+$ sed -e '/^==.*[^{]$/d' -e 's/==.*{/{/' supress.log >
supress.txt
+$ valgrind --suppressions=supress.txt ./a.out
+
+See also:
+https://www.valgrind.org/docs/manual/manual-core.html#manual-core.suppress
--
ASOU Masato
[PATCH] Fix valgrind abort
The Valgrind is aborted in OpenBSD current as follows:
$ sysctl -n kern.version
OpenBSD 6.8-beta (GENERIC.MP) #77: Wed Sep 23 15:36:00 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
$ valgrind /bin/ls
Abort trap
$
I made fix this abort.
comment? ok?
Index: Makefile
===
RCS file: /cvs/ports/devel/valgrind/Makefile,v
retrieving revision 1.24
diff -u -p -r1.24 Makefile
--- Makefile22 May 2020 08:51:24 - 1.24
+++ Makefile24 Sep 2020 07:21:20 -
@@ -7,7 +7,7 @@ CATEGORIES =devel
V =3.10.1
PV = 20160331
-REVISION = 17
+REVISION = 18
DISTNAME = valgrind-${V}
EXTRACT_SUFX = .tar.bz2
Index: patches/patch-coregrind_link_tool_exe_openbsd_in
===
RCS file:
/cvs/ports/devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in,v
retrieving revision 1.4
diff -u -p -r1.4 patch-coregrind_link_tool_exe_openbsd_in
--- patches/patch-coregrind_link_tool_exe_openbsd_in6 Nov 2019 05:25:13
- 1.4
+++ patches/patch-coregrind_link_tool_exe_openbsd_in24 Sep 2020 07:21:20
-
@@ -1,16 +1,40 @@
--- coregrind/link_tool_exe_openbsd.in.origFri Sep 27 10:40:06 2019
-+++ coregrind/link_tool_exe_openbsd.in Fri Sep 27 10:45:59 2019
-@@ -77,7 +77,12 @@
- my $origbase = 0x40;
- system(sprintf "sed -e 's|%x|%x|g' < $ldscript > $temp", $origbase,
$notebase);
coregrind/link_tool_exe_openbsd.in Fri Sep 25 00:50:44 2020
+@@ -63,22 +63,13 @@
+ # The cc invokation to do the final link
+ my $cc = $ARGV[1];
--my $cmd = sprintf "$cc -static -nopie -Wl,-Ttext=0x%x -Wl,-T,$temp",
$textbase;
+-# and the 'restargs' are argv[2 ..]
+# XXX The '-s' option was not specified when executing the install command.
+# Instead '--strip-all' is now executed at link time.
+# strip command rewrite offset and align in ELF file. Therefor, when valgrind
+# launch memcheck-amd64-openbsd, an Abort trap occurs in the execvp() system
+# call.
-+my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-Ttext=0x%x
-Wl,-T,$temp", $textbase;
++my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-Ttext=0x%x", "$ala
+ 0x1000";
+-# so, build up the complete command here:
+-# 'cc' -static -Ttext='ala' 'restargs'
+-
+-my $textbase = eval("$ala + 0x1000");
+-my $notebase = eval("$ala");
+-
+-my $ldscript = "/usr/libdata/ldscripts/elf_x86_64_obsd.x";
+-my $temp = `mktemp /tmp/XX`;
+-chomp($temp);
+-my $origbase = 0x40;
+-system(sprintf "sed -e 's|%x|%x|g' < $ldscript > $temp", $origbase,
$notebase);
+-
+-my $cmd = sprintf "$cc -static -nopie -Wl,-Ttext=0x%x -Wl,-T,$temp",
$textbase;
+-
# Add the rest of the parameters
foreach my $n (2 .. $#ARGV) {
+$cmd = "$cmd $ARGV[$n]";
+@@ -89,8 +80,6 @@
+
+ # Execute the command:
+ my $r = system("$cmd");
+-
+-unlink $temp;
+
+ if ($r == 0) {
+ exit 0;
--
ASOU Masato
Re: valgrind + llvm10
From: Martijn van Duren
Date: Mon, 14 Sep 2020 11:42:20 +0200
> On Mon, 2020-09-14 at 18:12 +0900, Masato Asou wrote:
>> Hi,
>>
>> From: Martijn van Duren
>> Date: Mon, 14 Sep 2020 10:43:28 +0200
>>
>> > I did some bisecting and it seems that the update to clang 10 broke
>> > valgrind. Specifically /usr/local/lib/valgrind/memcheck-amd64-openbsd:
>> >
>> > $ ktrace -i /usr/local/lib/valgrind/memcheck-amd64-openbsd
>> > Abort trap
>> > $ kdump
>> > 12913 ktrace RET ktrace 0
>> > 12913 ktrace CALL execve(0x7f7c6fca,0x7f7c6e68,0x7f7c6e78)
>> > 12913 ktrace NAMI "/usr/local/lib/valgrind/memcheck-amd64-openbsd"
>> > 12913 ktrace ARGS
>> > [0] = "/usr/local/lib/valgrind/memcheck-amd64-openbsd"
>>
>> Now, I am debugging this problem.
>>
>> > Compiling valgrind with CC=gcc gives the same result, so my guess is
>> > that the linker does something unexpected.
>>
>> Your guess is correct.
>>
>> Anyway, the following changes seems to work correctly.
>> I will report the patch to this mailing list in the next few days.
>>
>> --- a/devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in
>> +++ b/devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in
>> @@ -10,7 +10,7 @@
>> +# strip command rewrite offset and align in ELF file. Therefor, when
>> valgrind
>> +# launch memcheck-amd64-openbsd, an Abort trap occurs in the execvp()
>> system
>> +# call.
>> -+my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-Ttext=0x%x
>> -Wl,-T,$temp", $textbase;
>> ++my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-Ttext=0x%x",
>> $textbase;
>>
>> # Add the rest of the parameters
>> foreach my $n (2 .. $#ARGV) {
>> --
>> ASOU Masato
>>
>
> Thanks, that gets us a bit further, but it still crashes:
>
> $ cat test.c
> int
> main(int argc, char *argv[])
> {
> }
> $ make test && valgrind ./test
> `test' is up to date.
> ==57402== Memcheck, a memory error detector
> ==57402== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==57402== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
> ==57402== Command: ./test
> ==57402==
> ==57402==
> ==57402== Process terminating with default action of signal 11 (SIGSEGV):
> dumping core
> ==57402== Access not within mapped region at address 0x8016A00
> ==57402==at 0x4A680CB: __amd64_read_tcb (in /usr/lib/libc.so.96.0)
> ==57402==by 0x4A6803D: _thread_finalize (in /usr/lib/libc.so.96.0)
> ==57402==by 0x4A68120: __cxa_finalize (in /usr/lib/libc.so.96.0)
> ==57402==by 0x4AF2BF3: exit (in /usr/lib/libc.so.96.0)
> ==57402==by 0x109747: ___start (in ./test)
> ==57402== If you believe this happened as a result of a stack
> ==57402== overflow in your program's main thread (unlikely but
> ==57402== possible), you can try to increase the size of the
> ==57402== main thread stack using the --main-stacksize= flag.
> ==57402== The main thread stack size used in this run was 4194304.
>
> valgrind: m_coredump/coredump-elf.c:816 (void make_elf_coredump(ThreadId,
> const vki_siginfo_t *, ULong)): Assertion 'VG_(lseek)(core_fd,
> phdrs[idx].p_offset, VKI_SEEK_SET) == phdrs[idx].p_offset'
> failed.
>
> host stacktrace:
> ==57402==at 0x3804BA6C: ???
> ==57402==by 0x802A9AFDF: ???
> ==57402==by 0x38069590: ???
> ==57402==by 0x3804BA6B: ???
> ==57402==by 0x802A99FAF: ???
>
> sched status:
> running_tid=1
>
> Thread 1: status = VgTs_Runnable
> ==57402==at 0x4A680CB: __amd64_read_tcb (in /usr/lib/libc.so.96.0)
> ==57402==by 0x4A6803D: _thread_finalize (in /usr/lib/libc.so.96.0)
> ==57402==by 0x4A68120: __cxa_finalize (in /usr/lib/libc.so.96.0)
> ==57402==by 0x4AF2BF3: exit (in /usr/lib/libc.so.96.0)
> ==57402==by 0x109747: ___start (in ./test)
>
>
> Note: see also the FAQ in the source distribution.
> It contains workarounds to several common problems.
> In particular, if Valgrind aborted or crashed after
> identifying problems in your program, there's a good chance
> that fixing those problems will prevent Valgrind aborting or
> crashing, especially if it happened in m_mallocfree.c.
>
> If that doesn't help, please report this bug to: www.valgrind.org
>
> In the bug report, send all the above text, the valgrind
> version, and what OS and version you are using. Thanks.
>
>
I have no problems in my environments as below:
$ cat test.c
int
main(int argc, char *ar
Re: valgrind + llvm10
Hi,
From: Martijn van Duren
Date: Mon, 14 Sep 2020 10:43:28 +0200
> I did some bisecting and it seems that the update to clang 10 broke
> valgrind. Specifically /usr/local/lib/valgrind/memcheck-amd64-openbsd:
>
> $ ktrace -i /usr/local/lib/valgrind/memcheck-amd64-openbsd
> Abort trap
> $ kdump
> 12913 ktrace RET ktrace 0
> 12913 ktrace CALL execve(0x7f7c6fca,0x7f7c6e68,0x7f7c6e78)
> 12913 ktrace NAMI "/usr/local/lib/valgrind/memcheck-amd64-openbsd"
> 12913 ktrace ARGS
> [0] = "/usr/local/lib/valgrind/memcheck-amd64-openbsd"
Now, I am debugging this problem.
> Compiling valgrind with CC=gcc gives the same result, so my guess is
> that the linker does something unexpected.
Your guess is correct.
Anyway, the following changes seems to work correctly.
I will report the patch to this mailing list in the next few days.
--- a/devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in
+++ b/devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in
@@ -10,7 +10,7 @@
+# strip command rewrite offset and align in ELF file. Therefor, when valgrind
+# launch memcheck-amd64-openbsd, an Abort trap occurs in the execvp() system
+# call.
-+my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-Ttext=0x%x
-Wl,-T,$temp", $textbase;
++my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-Ttext=0x%x",
$textbase;
# Add the rest of the parameters
foreach my $n (2 .. $#ARGV) {
--
ASOU Masato
Re: [NEW] sysutils/fluent-bit
Hi, From: Stuart Henderson Date: Mon, 6 Jul 2020 10:55:14 +0100 > On 2020/07/06 16:30, Masato Asou wrote: >> Hi, >> >> I have already applied your previous patch. > > My mail was about several things. Some were fixed by the patch, some were not. > >> >> Several of these are in ports already (normally dependencies should be >> >> taken >> >> from ports rather than bundled - so that patches needed for working on >> >> OpenBSD, >> >> at least on some arches, are picked up - and so that security fixes don't >> >> have >> >> to be made in multiple places - for example onigmo/oniguruma is an old >> >> version >> >> missing security fixes). >> >> Builds for some of these do things like force using gcc as the compiler, >> >> setting opt flags like -O3 -funroll-loops which aren't allowed in ports. > > Ports should normally use dependencies from the ports tree, not bundled > ones. That way, when patches are made to fix some architecture, it fixes > things for all programs using the library. And when a security fix is > made, it doesn't require patches in separate copies across the ports tree. > > If that is absolutely unavoidable then the build process for all of > the different parts still needs to follow ports standards. Use the > correct compiler (normally "cc"/"c++" but can be overridden on the > make command line by setting CC/CXX variables). Use correct optimizer > flags (CFLAGS/CXXFLAGS). Not pick up any software which is installed > during the build unless listed as a dependency. I did not correctly understand the first reply from you. >> >> Those using autoconf bypass the normal ports infrastructure for this and >> >> pick up tools like gsed/ggrep if present at build time, which in a bulk >> >> build maybe removed part-way through the build. > > -> at the stages when "configure" is run during the build it can pick up > installed programs that are not listed as dependencies. in a bulk build, > packages are installed and deinstalled _all the time_ > >> >> cmake checks for some things which aren't listed as dependencies too (and >> >> finds them if installed), which need to be disabled properly or at least >> >> check >> >> that they don't break things if they're present when configure is run but >> >> removed during the build >> >> >> >> -- Could NOT find GTest (missing: GTEST_LIBRARY GTEST_INCLUDE_DIR >> >> GTEST_MAIN_LIBRARY) >> >> -- Found Doxygen: /usr/local/bin/doxygen (found version "1.8.18") found >> >> components: doxygen dot >> >> -- Found PythonInterp: /usr/local/bin/python3.8 (found version "3.8.2") >> >> -- Found PostgreSQL: /usr/local/lib/libpq.so.6.11 (found version "12.2") > > -> a port build must produce the same results whether or not other > packages are installed. either list all optional dependencies, or > disable them. > >> >> I've tidied up some things (diff below) but due to upstream's choices of >> >> how to do things this is going to be complicated to get in proper shape >> >> for >> >> commit. >> > >> >> Here is the difference between my first and last email. >> Am I misunderstanding something? > > The basic problem is that the way this software is normally built is not > really compatible with the way things are done in ports. I will review the change to fluent-bit again, but I need time to work on that. Thank you for your explanation. -- ASOU Masato
Re: [NEW] sysutils/fluent-bit
Hi,
I have already applied your previous patch.
From: Stuart Henderson
Date: Wed, 1 Jul 2020 10:36:41 +0100
> From my previous mail, I don't see that any of these have been addressed:
>
> On 2020/05/27 11:38, Stuart Henderson wrote:
>> Several of these are in ports already (normally dependencies should be taken
>> from ports rather than bundled - so that patches needed for working on
>> OpenBSD,
>> at least on some arches, are picked up - and so that security fixes don't
>> have
>> to be made in multiple places - for example onigmo/oniguruma is an old
>> version
>> missing security fixes).
>>
>> Builds for some of these do things like force using gcc as the compiler,
>> setting opt flags like -O3 -funroll-loops which aren't allowed in ports.
>> Those using autoconf bypass the normal ports infrastructure for this and
>> pick up tools like gsed/ggrep if present at build time, which in a bulk
>> build maybe removed part-way through the build.
>>
>> cmake checks for some things which aren't listed as dependencies too (and
>> finds them if installed), which need to be disabled properly or at least
>> check
>> that they don't break things if they're present when configure is run but
>> removed during the build
>>
>> -- Could NOT find GTest (missing: GTEST_LIBRARY GTEST_INCLUDE_DIR
>> GTEST_MAIN_LIBRARY)
>> -- Found Doxygen: /usr/local/bin/doxygen (found version "1.8.18") found
>> components: doxygen dot
>> -- Found PythonInterp: /usr/local/bin/python3.8 (found version "3.8.2")
>> -- Found PostgreSQL: /usr/local/lib/libpq.so.6.11 (found version "12.2")
>>
>> I've tidied up some things (diff below) but due to upstream's choices of
>> how to do things this is going to be complicated to get in proper shape for
>> commit.
>
Here is the difference between my first and last email.
Am I misunderstanding something?
--
ASOU Masato
diff -urN fluent-bit-1st/Makefile fluent-bit/Makefile
--- fluent-bit-1st/Makefile 2020-05-13 16:30:12.0 +0900
+++ fluent-bit/Makefile 2020-07-01 14:14:05.0 +0900
@@ -1,40 +1,43 @@
# $OpenBSD$
-PKG_ARCH = *
+COMMENT = fast log processor and forwarder
-COMMENT = Fast log processor and forwarder
-
-GH_ACCOUNT = fluent
-GH_PROJECT = fluent-bit
-GH_TAGNAME = v1.4.4
+VERSION = 1.4
+V =${VERSION}.6
CATEGORIES = sysutils
+DISTNAME = fluent-bit-${V}
+EXTRACT_SUFX = .tar.gz
HOMEPAGE = https://fluentbit.io/
+MASTER_SITES = ${HOMEPAGE:=releases/${VERSION}/}
#MAINTAINER =
# Apache License 2.0
PERMIT_PACKAGE = Yes
-PERMIT_DISTFILES = Yes
-MODULES= devel/cmake
-USE_NINJA =No
+WANTLIB += c c++abi m pthread
-# some Makefiles use "$<"
-USE_GMAKE =Yes
+MODULES= devel/cmake
-# CFLAGS "-frandom-seed=\$@" generated by lib/libbacktrace/configure
-# assumes a GNU libtool's behavior, our libtool doesn't behave like so.
-USE_LIBTOOL = gnu
+# hardcodes c++abi
+COMPILER = base-clang
-# Makefiles generated by cmake are using "$<"
+# calls out to $(MAKE) from build files for bundled dependencies,
+# some of which need gmake.
+USE_NINJA =No
+USE_GMAKE =Yes
CONFIGURE_ARGS += -DCMAKE_MAKE_PROGRAM:FILEPATH=${LOCALBASE}/bin/gmake
CONFIGURE_ARGS +=
-DCMAKE_INSTALL_SYSCONFDIR:PATH=${LOCALBASE}/share/examples
CONFIGURE_ARGS += -DWITHOUT_HEADERS=1
CONFIGURE_ARGS += -DFLB_CORO_STACK_SIZE=16384
+# CFLAGS "-frandom-seed=\$@" generated by lib/libbacktrace/configure
+# breaks with openbsd libtool
+CONFIGURE_ARGS += -DFLB_BACKTRACE=OFF
+
BUILD_DEPENDS =devel/bison
post-install:
diff -urN fluent-bit-1st/distinfo fluent-bit/distinfo
--- fluent-bit-1st/distinfo 2020-05-13 16:26:18.0 +0900
+++ fluent-bit/distinfo 2020-07-01 09:51:03.0 +0900
@@ -1,2 +1,2 @@
-SHA256 (fluent-bit-1.4.4.tar.gz) =
f9abc86ca56fbfc7b5c3fff1511f21e6eaa4c75cae7690e2fcca381872abf6f7
-SIZE (fluent-bit-1.4.4.tar.gz) = 12614962
+SHA256 (fluent-bit-1.4.6.tar.gz) =
4da02a9d0f42a82eab07ea3e5713007c0fd5539485da133515ae464789fc11fa
+SIZE (fluent-bit-1.4.6.tar.gz) = 12509211
diff -urN fluent-bit-1st/patches/patch-CMakeLists_txt
fluent-bit/patches/patch-CMakeLists_txt
--- fluent-bit-1st/patches/patch-CMakeLists_txt 1970-01-01 09:00:00.0
+0900
+++ fluent-bit/patches/patch-CMakeLists_txt 2020-06-01 15:08:59.0
+0900
@@ -0,0 +1,20 @@
+$OpenBSD$
+
+avoid gmake-ism, only used to strip off the build path from trace functions
+
+Index: CMakeLists.txt
+--- CMakeLists.txt.orig
CMakeLists.txt
+@@ -24,11 +24,7 @@ else()
+ set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall")
+ endif()
+
+-if(NOT ${CMAKE_SYSTEM_NAME} MATCHES "Windows")
+- set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -D__FILENAME__='\"$(subst
${CMAKE_SOURCE_DIR}/,,$(abspath $<))\"'")
+-else()
+- set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -D__FILENAME__=__FILE__")
+-endif()
++set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -D__FILENAME__=__FILE__")
+
+ include(GNUInstallDirs)
+
Re: [NEW] sysutils/fluent-bit
Hi,
From: Landry Breuil
Date: 2020-05-27 5:47:33
> On Wed, May 27, 2020 at 01:48:55PM +0900, Masato Asou wrote:
>> Hi,
>>
>> This is a new port sysutils/fluent-bit. Fluent bit is a Log Processor
>> and Forwarder.
>
> Great stuff, i think i had a look at it some years ago and it looked
> very-linuxy/not that much portable.. nice that you made it.
>
> some notes:
> * why USE_NINJA=No ?
> * why not taking maintainership ?
> * it feels weird to force gmake usage w/ cmake.. in which voodooo
> trickery does cmake end up generating $< -gmake rules ? cant the cmake
> stuff be fixed instead ?
> * 1.4.5 was released 2 days ago
> * many portability patches without comments.. are you planning to push
> those upstream via github ?
>
> other than that it reads good at first sight.
>
> Landry
The original version has been updated from 1.4.4 to 1.4.6.
The difference at the tail end is a comparison with the .tgz attached
to the email below.
ok?
From: Masato Asou
Date: Mon, 01 Jun 2020 17:07:34 +0900 (JST)
> From: Stuart Henderson
> Date: 2020-05-27 10:38:26
>
>> On 2020/05/27 07:47, Landry Breuil wrote:
>>> On Wed, May 27, 2020 at 01:48:55PM +0900, Masato Asou wrote:
>>> > Hi,
>>> >
>>> > This is a new port sysutils/fluent-bit. Fluent bit is a Log Processor
>>> > and Forwarder.
>>>
>>> Great stuff, i think i had a look at it some years ago and it looked
>>> very-linuxy/not that much portable.. nice that you made it.
>>>
>>> some notes:
>>> * why USE_NINJA=No ?
>>
>> Couple of reasons. One is that they don't want the full path in traces and
>> are
>> using some gmake-specific mess to define __FILENAME__ with the 'base' source
>> directory stripped off (that's easily avoided by using __FILE__ instead).
>> Another is that they bundle various dependencies and are building them by
>> calling $(MAKE). Also some of those dependencies use gmake-specific things.
>
>
>
> I've applied your patch.
>
> How about this patch.
diff --git a/sysutils/fluent-bit/Makefile b/sysutils/fluent-bit/Makefile
index 622f4aaea80..d4f2dae8abb 100644
--- a/sysutils/fluent-bit/Makefile
+++ b/sysutils/fluent-bit/Makefile
@@ -2,13 +2,15 @@
COMMENT = fast log processor and forwarder
-GH_ACCOUNT = fluent
-GH_PROJECT = fluent-bit
-GH_TAGNAME = v1.4.4
+VERSION = 1.4
+V =${VERSION}.6
CATEGORIES = sysutils
+DISTNAME = fluent-bit-${V}
+EXTRACT_SUFX = .tar.gz
HOMEPAGE = https://fluentbit.io/
+MASTER_SITES = ${HOMEPAGE:=releases/${VERSION}/}
#MAINTAINER =
diff --git a/sysutils/fluent-bit/distinfo b/sysutils/fluent-bit/distinfo
index e3e4e31ba17..8adc6e0442b 100644
--- a/sysutils/fluent-bit/distinfo
+++ b/sysutils/fluent-bit/distinfo
@@ -1,2 +1,2 @@
-SHA256 (fluent-bit-1.4.4.tar.gz) =
f9abc86ca56fbfc7b5c3fff1511f21e6eaa4c75cae7690e2fcca381872abf6f7
-SIZE (fluent-bit-1.4.4.tar.gz) = 12614962
+SHA256 (fluent-bit-1.4.6.tar.gz) =
4da02a9d0f42a82eab07ea3e5713007c0fd5539485da133515ae464789fc11fa
+SIZE (fluent-bit-1.4.6.tar.gz) = 12509211
diff --git a/sysutils/fluent-bit/patches/patch-plugins_in_tail_tail_file_c
b/sysutils/fluent-bit/patches/patch-plugins_in_tail_tail_file_c
index 98028f8e44c..408b2e887c1 100644
--- a/sysutils/fluent-bit/patches/patch-plugins_in_tail_tail_file_c
+++ b/sysutils/fluent-bit/patches/patch-plugins_in_tail_tail_file_c
@@ -3,7 +3,7 @@ $OpenBSD$
Index: plugins/in_tail/tail_file.c
--- plugins/in_tail/tail_file.c.orig
+++ plugins/in_tail/tail_file.c
-@@ -1041,9 +1041,8 @@
+@@ -1053,9 +1053,8 @@
{
int ret;
char *buf;
@@ -15,7 +15,7 @@ Index: plugins/in_tail/tail_file.c
#elif defined(__APPLE__)
char path[PATH_MAX];
#elif defined(_MSC_VER)
-@@ -1056,21 +1055,24 @@
+@@ -1068,21 +1067,24 @@
return NULL;
}
diff --git a/sysutils/fluent-bit/patches/patch-src_CMakeLists_txt
b/sysutils/fluent-bit/patches/patch-src_CMakeLists_txt
index aef2a395fcc..a73f2dc2428 100644
--- a/sysutils/fluent-bit/patches/patch-src_CMakeLists_txt
+++ b/sysutils/fluent-bit/patches/patch-src_CMakeLists_txt
@@ -3,7 +3,7 @@ $OpenBSD$
Index: src/CMakeLists.txt
--- src/CMakeLists.txt.orig
+++ src/CMakeLists.txt
-@@ -191,6 +191,13 @@ if(CMAKE_SYSTEM_NAME MATCHES "Linux")
+@@ -192,6 +192,13 @@
)
endif()
diff --git a/sysutils/fluent-bit/patches/patch-src_flb_scheduler_c
b/sysutils/fluent-bit/patches/patch-src_flb_scheduler_c
index 539e9efafdb..19b75431bca 100644
--- a/sysutils/fluent-bit/patches/patch-src_flb_scheduler_c
+++ b/sysutils/fluent-bit/patches/patch-src_flb_scheduler_c
@@ -3,7 +3,7 @@ $OpenBSD$
Index: src/flb_scheduler.c
--- src/flb_scheduler.c.orig
+++ src/flb_scheduler.c
-@@ -376,7 +376,7 @@ int flb_sched_event_handler(struct flb_config *c
Re: [NEW] sysutils/fluent-bit
From: Stuart Henderson Date: 2020-05-27 10:38:26 > On 2020/05/27 07:47, Landry Breuil wrote: >> On Wed, May 27, 2020 at 01:48:55PM +0900, Masato Asou wrote: >> > Hi, >> > >> > This is a new port sysutils/fluent-bit. Fluent bit is a Log Processor >> > and Forwarder. >> >> Great stuff, i think i had a look at it some years ago and it looked >> very-linuxy/not that much portable.. nice that you made it. >> >> some notes: >> * why USE_NINJA=No ? > > Couple of reasons. One is that they don't want the full path in traces and are > using some gmake-specific mess to define __FILENAME__ with the 'base' source > directory stripped off (that's easily avoided by using __FILE__ instead). > Another is that they bundle various dependencies and are building them by > calling $(MAKE). Also some of those dependencies use gmake-specific things. I've applied your patch. How about this patch. -- ASOU Masato fluent-bit.tgz Description: Binary data
Re: [NEW] sysutils/fluent-bit
From: Landry Breuil Date: 2020-05-27 5:47:33 > On Wed, May 27, 2020 at 01:48:55PM +0900, Masato Asou wrote: >> Hi, >> >> This is a new port sysutils/fluent-bit. Fluent bit is a Log Processor >> and Forwarder. > > Great stuff, i think i had a look at it some years ago and it looked > very-linuxy/not that much portable.. nice that you made it. Thank you. > some notes: > * why USE_NINJA=No ? When I set USE_NINJA=Yes, I got following error: ===> Configuring for fluent-bit-1.4.4 -- The C compiler identification is Clang 8.0.1 -- The CXX compiler identification is Clang 8.0.1 -- Check for working C compiler: /usr/ports/pobj/fluent-bit-1.4.4/bin/cc CMake Error: The detected version of Ninja (GNU Make 4.3 Built for x86_64-unknown-openbsd6.7 Copyright (C) 1988-2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.) is less than the version of Ninja required by CMake (1.3). CMake Error at /usr/local/share/cmake/Modules/CMakeTestCCompiler.cmake:44 (try_compile): Failed to generate test project build system. Call Stack (most recent call first): CMakeLists.txt:2 (project) -- Configuring incomplete, errors occurred! See also "/home/asou/develop/ports/pobj/fluent-bit-1.4.4/build-amd64/CMakeFiles/CMakeOutput.log". *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2746 'do-configure': @cd /usr/ports/pobj/fluent-bit-1.4.4/build-amd64 && /usr/bin...) *** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2766 '/usr/ports/pobj/fluent-bit-1.4.4/build-amd64/.configure_done': @cd /usr/por...) *** Error 2 in /usr/ports/sysutils/fluent-bit (/usr/ports/infrastructure/mk/bsd.port.mk:2451 'all': @lock=fluent-bit-1.4.4; export _LOCKS_H...) > * why not taking maintainership ? There is a way to do it, but I wanted to use it immediately. > * it feels weird to force gmake usage w/ cmake.. in which voodooo > trickery does cmake end up generating $< -gmake rules ? I got following error: make -f lib/jsmn/CMakeFiles/jsmn.dir/build.make lib/jsmn/CMakeFiles/jsmn.dir/depend cd /home/asou/develop/ports/pobj/fluent-bit-1.4.4/build-amd64 && /usr/local/bin/cmake -E cmake_depends "Unix Makefiles" /usr/ports/pobj/fluent-bit-1.4.4/fluent-b it-1.4.4 /usr/ports/pobj/fluent-bit-1.4.4/fluent-bit-1.4.4/lib/jsmn /home/asou/develop/ports/pobj/fluent-bit-1.4.4/build-amd64 /home/asou/develop/ports/pobj/flue nt-bit-1.4.4/build-amd64/lib/jsmn /home/asou/develop/ports/pobj/fluent-bit-1.4.4/build-amd64/lib/jsmn/CMakeFiles/jsmn.dir/DependInfo.cmake --color= Dependee "/home/asou/develop/ports/pobj/fluent-bit-1.4.4/build-amd64/lib/jsmn/CMakeFiles/jsmn.dir/DependInfo.cmake" is newer than depender "/home/asou/develop/po rts/pobj/fluent-bit-1.4.4/build-amd64/lib/jsmn/CMakeFiles/jsmn.dir/depend.internal". Dependee "/home/asou/develop/ports/pobj/fluent-bit-1.4.4/build-amd64/lib/jsmn/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/home/asou/deve lop/ports/pobj/fluent-bit-1.4.4/build-amd64/lib/jsmn/CMakeFiles/jsmn.dir/depend.internal". Scanning dependencies of target jsmn make -f lib/jsmn/CMakeFiles/jsmn.dir/build.make lib/jsmn/CMakeFiles/jsmn.dir/build [ 2%] Building C object lib/jsmn/CMakeFiles/jsmn.dir/jsmn.c.o Using $< in a non-suffix rule context is a GNUmake idiom (lib/jsmn/CMakeFiles/jsmn.dir/build.make:63) *** Error 2 in . (CMakeFiles/Makefile2:2099 'lib/jsmn/CMakeFiles/jsmn.dir/all') *** Error 2 in /home/asou/develop/ports/pobj/fluent-bit-1.4.4/build-amd64 (Makefile:152 'all') *** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2785 '/usr/ports/pobj/fluent-bit-1.4.4/build-amd64/.build_done': @cd /usr/ports/p...) *** Error 2 in /usr/ports/sysutils/fluent-bit (/usr/ports/infrastructure/mk/bsd.port.mk:2451 'all': @lock=fluent-bit-1.4.4; export _LOCKS_H...) > cant the cmake > stuff be fixed instead ? I will look into it. But I need more time. > * 1.4.5 was released 2 days ago I will be able to respond to 1.4.5 soon, maybe. > * many portability patches without comments.. I will add some comments. > are you planning to push > those upstream via github ? Yes I am, if possible. > other than that it reads good at first sight. Thank you! Now, I am confirming the folloeing reply: > From: Stuart Henderson > Date: 2020-05-27 10:38:26 > Message-ID: <20200527103826.gj27...@symphytum.spacehopper.org> -- ASOU Masato
[NEW] sysutils/fluent-bit
Hi, This is a new port sysutils/fluent-bit. Fluent bit is a Log Processor and Forwarder. --- pkg/DESCR: Fluent Bit is a fast log processor and forwarder. It allows to collect log events or metrics from different sources, process them and deliver them to different backends such as Fluentd, Elasticsearch, NATS, InfluxDB or any custom HTTP end-point within others. --- ok? -- ASOU Masato fluent-bit.tgz Description: Binary data
Re: [PATCH] Fix Valgrind reports invalid write
From: Jeremie Courreges-Anglas
Date: Thu, 07 May 2020 14:12:08 +0200
> On Thu, May 07 2020, Masato Asou wrote:
>> hi,
>>
>> Valgrind reports the correct wirte as an invalid write. It is
>> occurring at /usr/libexec/ld.so.
>>
>> I run following program.
>>
>> $ cat main.c
>> #include
>>
>> int
>> main(int argc, char *argv[])
>> {
>> printf("Hello, world\n");
>> return (0);
>> }
>> $ cc -g main.c
>> $ valgrind ./a.out
>> ==46291== Memcheck, a memory error detector
>> ==46291== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
>> ==46291== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
>> ==46291== Command: /home/asou/tmp/a.out
>> ==46291==
>> ==46291== Invalid write of size 1
>> ==46291==at 0x410730C: ???
>> ==46291==by 0x4103CC8: ???
>> ==46291==by 0x41032EE: ???
>> ==46291==by 0x4102605: ???
>> ==46291== Address 0x40052d0 is not stack'd, malloc'd or (recently) free'd
>> ==46291==
>> ==46291== Invalid write of size 1
>> ==46291==at 0x410730E: ???
>> ==46291==by 0x4103CC8: ???
>> ==46291==by 0x41032EE: ???
>> ==46291==by 0x4102605: ???
>> ==46291== Address 0x40052d1 is not stack'd, malloc'd or (recently) free'd
>> ==46291==
>>
>>
>>
>> ==46291== For counts of detected and suppressed errors, rerun with: -v
>> ==46291== Use --track-origins=yes to see where uninitialised values come from
>> ==46291== ERROR SUMMARY: 3209 errors from 357 contexts (suppressed: 0 from 0)
>> $
>>
>> I got 3209 errors.
>>
>> However, when the following patch was applied, the error was reduced
>> to four as below:
>
> Hah, that look much better.
>
>> $ valgrind ./a.out
>> ==7449== Memcheck, a memory error detector
>> ==7449== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
>> ==7449== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
>> ==7449== Command: /home/asou/tmp/a.out
>> ==7449==
>> ==7449== Use of uninitialised value of size 8
>> ==7449==at 0x4ACB969: write (sys/w_write.c:26)
>> ==7449==by 0x4AB60DF: __sflush (stdio/fflush.c:80)
>> ==7449==by 0x4A491F1: __sfvwrite (stdio/fvwrite.c:191)
>> ==7449==by 0x4A62F62: __sprint (stdio/vfprintf.c:108)
>> ==7449==by 0x4A62F62: __vfprintf (stdio/vfprintf.c:1067)
>> ==7449==by 0x4A5F151: vfprintf (stdio/vfprintf.c:263)
>> ==7449==by 0x4A43DB0: printf (stdio/printf.c:44)
>> ==7449==by 0x109374: main (main.c:6)
>> ==7449==
>> ==7449== Use of uninitialised value of size 8
>> ==7449==at 0x4ACB97A: write (sys/w_write.c:26)
>> ==7449==by 0x4AB60DF: __sflush (stdio/fflush.c:80)
>> ==7449==by 0x4A491F1: __sfvwrite (stdio/fvwrite.c:191)
>> ==7449==by 0x4A62F62: __sprint (stdio/vfprintf.c:108)
>> ==7449==by 0x4A62F62: __vfprintf (stdio/vfprintf.c:1067)
>> ==7449==by 0x4A5F151: vfprintf (stdio/vfprintf.c:263)
>> ==7449==by 0x4A43DB0: printf (stdio/printf.c:44)
>> ==7449==by 0x109374: main (main.c:6)
>> ==7449==
>> Hello, world
>> ==7449== Use of uninitialised value of size 8
>> ==7449==at 0x4ACB98E: write (sys/w_write.c:28)
>> ==7449==by 0x4AB60DF: __sflush (stdio/fflush.c:80)
>> ==7449==by 0x4A491F1: __sfvwrite (stdio/fvwrite.c:191)
>> ==7449==by 0x4A62F62: __sprint (stdio/vfprintf.c:108)
>> ==7449==by 0x4A62F62: __vfprintf (stdio/vfprintf.c:1067)
>> ==7449==by 0x4A5F151: vfprintf (stdio/vfprintf.c:263)
>> ==7449==by 0x4A43DB0: printf (stdio/printf.c:44)
>> ==7449==by 0x109374: main (main.c:6)
>> ==7449==
>> ==7449== Use of uninitialised value of size 8
>> ==7449==at 0x4ACC31C: _thread_finalize (stdlib/atexit.c:131)
>> ==7449==by 0x4ACC31C: __cxa_finalize (stdlib/atexit.c:153)
>> ==7449==by 0x4AD13C0: exit (stdlib/exit.c:54)
>> ==7449==by 0x109141: ___start (in /home/asou/tmp/a.out)
>> ==7449==
>> ==7449==
>> ==7449== FILE DESCRIPTORS: 3 open at exit.
>> ==7449== Open file descriptor 2:
>> ==7449==
>> ==7449==
>> ==7449== Open file descriptor 1:
>> ==7449==
>> ==7449==
>> ==7449== Open file descriptor 0:
>> ==7449==
>> ==7449==
>> ==7449==
>> ==7449== HEAP SUMMARY:
>> ==7449== in use at exit: 65,536 bytes in 1 blocks
>> ==7449== total heap usage: 1 allocs, 0 frees, 65,536 bytes allocated
>> ==7449==
>> ==7449== LEAK SUMMARY:
>> ==7449==definitely lost: 0 bytes in 0 block
[PATCH] Fix Valgrind reports invalid write
hi,
Valgrind reports the correct wirte as an invalid write. It is
occurring at /usr/libexec/ld.so.
I run following program.
$ cat main.c
#include
int
main(int argc, char *argv[])
{
printf("Hello, world\n");
return (0);
}
$ cc -g main.c
$ valgrind ./a.out
==46291== Memcheck, a memory error detector
==46291== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==46291== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==46291== Command: /home/asou/tmp/a.out
==46291==
==46291== Invalid write of size 1
==46291==at 0x410730C: ???
==46291==by 0x4103CC8: ???
==46291==by 0x41032EE: ???
==46291==by 0x4102605: ???
==46291== Address 0x40052d0 is not stack'd, malloc'd or (recently) free'd
==46291==
==46291== Invalid write of size 1
==46291==at 0x410730E: ???
==46291==by 0x4103CC8: ???
==46291==by 0x41032EE: ???
==46291==by 0x4102605: ???
==46291== Address 0x40052d1 is not stack'd, malloc'd or (recently) free'd
==46291==
==46291== For counts of detected and suppressed errors, rerun with: -v
==46291== Use --track-origins=yes to see where uninitialised values come from
==46291== ERROR SUMMARY: 3209 errors from 357 contexts (suppressed: 0 from 0)
$
I got 3209 errors.
However, when the following patch was applied, the error was reduced
to four as below:
$ valgrind ./a.out
==7449== Memcheck, a memory error detector
==7449== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==7449== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==7449== Command: /home/asou/tmp/a.out
==7449==
==7449== Use of uninitialised value of size 8
==7449==at 0x4ACB969: write (sys/w_write.c:26)
==7449==by 0x4AB60DF: __sflush (stdio/fflush.c:80)
==7449==by 0x4A491F1: __sfvwrite (stdio/fvwrite.c:191)
==7449==by 0x4A62F62: __sprint (stdio/vfprintf.c:108)
==7449==by 0x4A62F62: __vfprintf (stdio/vfprintf.c:1067)
==7449==by 0x4A5F151: vfprintf (stdio/vfprintf.c:263)
==7449==by 0x4A43DB0: printf (stdio/printf.c:44)
==7449==by 0x109374: main (main.c:6)
==7449==
==7449== Use of uninitialised value of size 8
==7449==at 0x4ACB97A: write (sys/w_write.c:26)
==7449==by 0x4AB60DF: __sflush (stdio/fflush.c:80)
==7449==by 0x4A491F1: __sfvwrite (stdio/fvwrite.c:191)
==7449==by 0x4A62F62: __sprint (stdio/vfprintf.c:108)
==7449==by 0x4A62F62: __vfprintf (stdio/vfprintf.c:1067)
==7449==by 0x4A5F151: vfprintf (stdio/vfprintf.c:263)
==7449==by 0x4A43DB0: printf (stdio/printf.c:44)
==7449==by 0x109374: main (main.c:6)
==7449==
Hello, world
==7449== Use of uninitialised value of size 8
==7449==at 0x4ACB98E: write (sys/w_write.c:28)
==7449==by 0x4AB60DF: __sflush (stdio/fflush.c:80)
==7449==by 0x4A491F1: __sfvwrite (stdio/fvwrite.c:191)
==7449==by 0x4A62F62: __sprint (stdio/vfprintf.c:108)
==7449==by 0x4A62F62: __vfprintf (stdio/vfprintf.c:1067)
==7449==by 0x4A5F151: vfprintf (stdio/vfprintf.c:263)
==7449==by 0x4A43DB0: printf (stdio/printf.c:44)
==7449==by 0x109374: main (main.c:6)
==7449==
==7449== Use of uninitialised value of size 8
==7449==at 0x4ACC31C: _thread_finalize (stdlib/atexit.c:131)
==7449==by 0x4ACC31C: __cxa_finalize (stdlib/atexit.c:153)
==7449==by 0x4AD13C0: exit (stdlib/exit.c:54)
==7449==by 0x109141: ___start (in /home/asou/tmp/a.out)
==7449==
==7449==
==7449== FILE DESCRIPTORS: 3 open at exit.
==7449== Open file descriptor 2:
==7449==
==7449==
==7449== Open file descriptor 1:
==7449==
==7449==
==7449== Open file descriptor 0:
==7449==
==7449==
==7449==
==7449== HEAP SUMMARY:
==7449== in use at exit: 65,536 bytes in 1 blocks
==7449== total heap usage: 1 allocs, 0 frees, 65,536 bytes allocated
==7449==
==7449== LEAK SUMMARY:
==7449==definitely lost: 0 bytes in 0 blocks
==7449==indirectly lost: 0 bytes in 0 blocks
==7449== possibly lost: 0 bytes in 0 blocks
==7449==still reachable: 65,536 bytes in 1 blocks
==7449== suppressed: 0 bytes in 0 blocks
==7449== Rerun with --leak-check=full to see details of leaked memory
==7449==
==7449== For counts of detected and suppressed errors, rerun with: -v
==7449== Use --track-origins=yes to see where uninitialised values come from
==7449== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0)
$
The patch to Makefile is a temporary. Because, my previous patch
https://marc.info/?l=openbsd-ports=158624064212984=2
does not get OK.
ok?
Index: Makefile
===
RCS file: /cvs/ports/devel/valgrind/Makefile,v
retrieving revision 1.23
diff -u -p -u -r1.23 Makefile
--- Makefile23 Dec 2019 23:26:32 - 1.23
+++ Makefile30 Apr 2020 06:39:41 -
@@ -7,7 +7,7 @@ CATEGORIES =devel
V =3.10.1
PV = 20160331
-REVISION = 16
+REVISION = 17
DISTNAME = valgrind-${V}
EXTRACT_SUFX =
Re: [PATCH] Valgrind print symbol of ld.so
From: Masato Asou
Date: Fri, 03 Apr 2020 15:24:44 +0900 (JST)
> Sorry, this patch is not correct. I'm canceling this patch. I'll
> consder it again.
>
> From: Masato Asou
> Date: Fri, 03 Apr 2020 12:24:32 +0900 (JST)
>
>> Hello,
>>
>> I made patch for print symbold of ld.so, if error was occured as
>> below:
I was corrected previous patch.
ok?
Index: Makefile
===
RCS file: /cvs/ports/devel/valgrind/Makefile,v
retrieving revision 1.23
diff -u -p -r1.23 Makefile
--- Makefile23 Dec 2019 23:26:32 - 1.23
+++ Makefile7 Apr 2020 00:21:47 -
@@ -7,7 +7,7 @@ CATEGORIES =devel
V =3.10.1
PV = 20160331
-REVISION = 16
+REVISION = 17
DISTNAME = valgrind-${V}
EXTRACT_SUFX = .tar.bz2
Index: patches/patch-coregrind_m_libcfile_c
===
RCS file: patches/patch-coregrind_m_libcfile_c
diff -N patches/patch-coregrind_m_libcfile_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-coregrind_m_libcfile_c7 Apr 2020 00:21:47 -
@@ -0,0 +1,39 @@
+$OpenBSD$
+
+--- coregrind/m_libcfile.c.orig
coregrind/m_libcfile.c
+@@ -40,6 +40,9 @@
+ #include "pub_core_xarray.h"
+ #include "pub_core_clientstate.h" // VG_(fd_hard_limit)
+ #include "pub_core_syscall.h"
++#if defined(VGO_openbsd)
++#include "pub_core_syswrap.h"
++#endif
+
+ /* IMPORTANT: on Darwin it is essential to use the _nocancel versions
+of syscalls rather than the vanilla version, if a _nocancel version
+@@ -174,6 +177,14 @@
+ # elif defined(VGO_linux) || defined(VGO_freebsd) || defined(VGO_openbsd)
+SysRes res = VG_(do_syscall3)(__NR_open,
+ (UWord)pathname, flags, mode);
++#if defined(VGO_openbsd)
++ // Track opened files by Valgrind so that we can look up filenames for
++ // mapped vnodes via the recorded table, instead of relying on procfs or
++ // kvm. This is possible as all executables and related files (dynamic
++ // linkder etc.) are all opened by host (Valgrind).
++ VG_(record_fd_open_with_given_name)(-1, sr_Res(res), (char *)pathname);
++ VG_(mark_fd_as_internal)(-1, sr_Res(res));
++#endif
+ # elif defined(VGO_darwin)
+SysRes res = VG_(do_syscall3)(__NR_open_nocancel,
+ (UWord)pathname, flags, mode);
+@@ -198,6 +209,9 @@
+/* Hmm. Return value is not checked. That's uncool. */
+ # if defined(VGO_linux) || defined(VGO_freebsd) || defined(VGO_openbsd)
+(void)VG_(do_syscall1)(__NR_close, fd);
++#if defined(VGO_openbsd)
++ VG_(record_fd_close)(fd);
++#endif
+ # elif defined(VGO_darwin)
+(void)VG_(do_syscall1)(__NR_close_nocancel, fd);
+ # else
Index: patches/patch-coregrind_m_main_c
===
RCS file: /cvs/ports/devel/valgrind/patches/patch-coregrind_m_main_c,v
retrieving revision 1.3
diff -u -p -r1.3 patch-coregrind_m_main_c
--- patches/patch-coregrind_m_main_c2 Oct 2019 17:19:29 - 1.3
+++ patches/patch-coregrind_m_main_c7 Apr 2020 00:21:47 -
@@ -71,7 +71,24 @@ Index: coregrind/m_main.c
// Get the current process stack rlimit.
VG_(getrlimit)(VKI_RLIMIT_STACK, _(client_rlimit_stack));
-@@ -2433,6 +2468,10 @@
+@@ -1834,7 +1869,16 @@
+// Set default vex control params
+LibVEX_default_VexControl(& VG_(clo_vex_control));
+
++#if defined(VGO_openbsd)
+//--
++ // setup file descriptors
++ // p: n/a
++ //--
++ VG_(debugLog)(1, "main", "Setup file descriptors\n");
++ setup_file_descriptors();
++#endif
++
++ //--
+// Load client executable, finding in $PATH if necessary
+// p: early_process_cmd_line_options() [for 'exec', 'need_help',
+// clo_max_stackframe,
+@@ -2433,6 +2477,10 @@
VG_(address_of_m_main_shutdown_actions_NORETURN)
= & shutdown_actions_NORETURN;
@@ -82,7 +99,7 @@ Index: coregrind/m_main.c
/* Run the first thread, eventually ending up at the continuation
address. */
VG_(main_thread_wrapper_NORETURN)(1);
-@@ -3159,6 +3198,8 @@
+@@ -3159,6 +3207,8 @@
"__start:\n"
/* pass args (long argc, char **argv, ...) on stack */
"\tmovq %rsp, %rdi\n"
@@ -91,7 +108,7 @@ Index: coregrind/m_main.c
/* set up the new stack in %rsi */
"\tmovq $vgPlain_interim_stack, %rsi\n"
"\taddq $"VG_STRINGIFY(VG_STACK_GUARD_SZB)", %rsi\n"
-@@ -3166,6 +3207,9 @@
+@@ -3166,6 +3216,9 @@
&quo
Re: [PATCH] Valgrind print symbol of ld.so
Sorry, this patch is not correct. I'm canceling this patch. I'll
consder it again.
--
ASOU Masato
From: Masato Asou
Date: Fri, 03 Apr 2020 12:24:32 +0900 (JST)
> Hello,
>
> I made patch for print symbold of ld.so, if error was occured as
> below:
>
>
> Before apply this patch:
> $ valgrind ./a.out
> ==62211== Memcheck, a memory error detector
> ==62211== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et
> al.
> ==62211== Using Valgrind-3.10.1 and LibVEX; rerun with -h for
> copyright info
> ==62211== Command: ./a.out
> ==62211==
> ==62211== Invalid write of size 1
> ==62211==at 0x4108E72: ???
> ==62211==by 0x4108374: ???
> ==62211==by 0x41096FA: ???
> ==62211==by 0x4102D4E: ???
> ==62211==by 0x4103986: ???
> ==62211==by 0x4104535: ???
> ==62211== Address 0x40052a0 is not stack'd, malloc'd or (recently) free'd
> ==62211==
>
>
>
>
> After apply this patch:
> $ valgrind ./a.out
> ==81691== Memcheck, a memory error detector
> ==81691== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et
> al.
> ==81691== Using Valgrind-3.10.1 and LibVEX; rerun with -h for
> copyright info
> ==81691== Command: ./a.out
> ==81691==
> ==81691== Invalid write of size 1
> ==81691==at 0x4108E72: chacha_encrypt_bytes (chacha_private.h:191)
> ==81691==by 0x4108374: _dl_arc4randombuf (util.c:98)
> ==81691==by 0x41096FA: rbytes_init (malloc.c:187)
> ==81691==by 0x4102D4E: _dl_malloc_init (in /usr/libexec/ld.so)
> ==81691==by 0x4103986: _dl_boot (in /usr/libexec/ld.so)
> ==81691==by 0x4104535: _dl_start (in /usr/libexec/ld.so)
> ==81691== Address 0x40053e0 is not stack'd, malloc'd or (recently) free'd
> ==81691==
>
>
>
> Regards
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/valgrind/Makefile,v
> retrieving revision 1.23
> diff -u -p -r1.23 Makefile
> --- Makefile 23 Dec 2019 23:26:32 - 1.23
> +++ Makefile 3 Apr 2020 03:12:38 -
> @@ -7,7 +7,7 @@ CATEGORIES = devel
>
> V = 3.10.1
> PV = 20160331
> -REVISION = 16
> +REVISION = 17
> DISTNAME = valgrind-${V}
> EXTRACT_SUFX = .tar.bz2
>
> Index: patches/patch-coregrind_m_libcfile_c
> ===
> RCS file: patches/patch-coregrind_m_libcfile_c
> diff -N patches/patch-coregrind_m_libcfile_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-coregrind_m_libcfile_c 3 Apr 2020 03:12:38 -
> @@ -0,0 +1,129 @@
> +--- coregrind/m_libcfile.c
> coregrind/m_libcfile.c
> +@@ -40,6 +40,9 @@
> + #include "pub_core_xarray.h"
> + #include "pub_core_clientstate.h" // VG_(fd_hard_limit)
> + #include "pub_core_syscall.h"
> ++#if defined(VGO_openbsd)
> ++#include "pub_core_mallocfree.h"
> ++#endif
> +
> + /* IMPORTANT: on Darwin it is essential to use the _nocancel versions
> +of syscalls rather than the vanilla version, if a _nocancel version
> +@@ -165,6 +168,90 @@
> + }
> + #endif
> +
> ++#if defined(VGO_openbsd)
> ++/* -
> ++ File-descriptor tracking
> ++ -- */
> ++
> ++/* One of these is allocated for each open file descriptor. */
> ++typedef struct OpenFd
> ++{
> ++ Int fd;/* The file descriptor */
> ++ HChar *pathname; /* NULL if not a regular file or unknown
> */
> ++ struct OpenFd *next, *prev;
> ++} OpenFd;
> ++
> ++/* List of allocated file descriptors. */
> ++static OpenFd *opened_fds = NULL;
> ++
> ++/* Note the fact that a file descriptor was just closed. */
> ++static
> ++void delete_fd(Int fd)
> ++{
> ++ OpenFd *i = opened_fds;
> ++
> ++ while(i) {
> ++ if(i->fd == fd) {
> ++ if(i->prev)
> ++i->prev->next = i->next;
> ++ else
> ++opened_fds = i->next;
> ++ if(i->next)
> ++i->next->prev = i->prev;
> ++ if(i->pathname)
> ++VG_(arena_free) (VG_AR_CORE, i->pathname);
> ++ VG_(arena_free) (VG_AR_CORE, i);
> ++ break;
> ++ }
> ++ i = i->next;
> ++ }
> ++}
> ++
> ++/* Note the fact that a file descriptor was just opened. */
> ++static
> ++void register_fd(Int fd, const HChar *pathname)
> ++{
> ++ OpenFd *i;
> ++
> ++ /* Check to see if this fd is already open. */
> ++
[PATCH] Valgrind print symbol of ld.so
Hello,
I made patch for print symbold of ld.so, if error was occured as
below:
Before apply this patch:
$ valgrind ./a.out
==62211== Memcheck, a memory error detector
==62211== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et
al.
==62211== Using Valgrind-3.10.1 and LibVEX; rerun with -h for
copyright info
==62211== Command: ./a.out
==62211==
==62211== Invalid write of size 1
==62211==at 0x4108E72: ???
==62211==by 0x4108374: ???
==62211==by 0x41096FA: ???
==62211==by 0x4102D4E: ???
==62211==by 0x4103986: ???
==62211==by 0x4104535: ???
==62211== Address 0x40052a0 is not stack'd, malloc'd or (recently) free'd
==62211==
After apply this patch:
$ valgrind ./a.out
==81691== Memcheck, a memory error detector
==81691== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et
al.
==81691== Using Valgrind-3.10.1 and LibVEX; rerun with -h for
copyright info
==81691== Command: ./a.out
==81691==
==81691== Invalid write of size 1
==81691==at 0x4108E72: chacha_encrypt_bytes (chacha_private.h:191)
==81691==by 0x4108374: _dl_arc4randombuf (util.c:98)
==81691==by 0x41096FA: rbytes_init (malloc.c:187)
==81691==by 0x4102D4E: _dl_malloc_init (in /usr/libexec/ld.so)
==81691==by 0x4103986: _dl_boot (in /usr/libexec/ld.so)
==81691==by 0x4104535: _dl_start (in /usr/libexec/ld.so)
==81691== Address 0x40053e0 is not stack'd, malloc'd or (recently) free'd
==81691==
Regards
Index: Makefile
===
RCS file: /cvs/ports/devel/valgrind/Makefile,v
retrieving revision 1.23
diff -u -p -r1.23 Makefile
--- Makefile23 Dec 2019 23:26:32 - 1.23
+++ Makefile3 Apr 2020 03:12:38 -
@@ -7,7 +7,7 @@ CATEGORIES =devel
V =3.10.1
PV = 20160331
-REVISION = 16
+REVISION = 17
DISTNAME = valgrind-${V}
EXTRACT_SUFX = .tar.bz2
Index: patches/patch-coregrind_m_libcfile_c
===
RCS file: patches/patch-coregrind_m_libcfile_c
diff -N patches/patch-coregrind_m_libcfile_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-coregrind_m_libcfile_c3 Apr 2020 03:12:38 -
@@ -0,0 +1,129 @@
+--- coregrind/m_libcfile.c
coregrind/m_libcfile.c
+@@ -40,6 +40,9 @@
+ #include "pub_core_xarray.h"
+ #include "pub_core_clientstate.h" // VG_(fd_hard_limit)
+ #include "pub_core_syscall.h"
++#if defined(VGO_openbsd)
++#include "pub_core_mallocfree.h"
++#endif
+
+ /* IMPORTANT: on Darwin it is essential to use the _nocancel versions
+of syscalls rather than the vanilla version, if a _nocancel version
+@@ -165,6 +168,90 @@
+ }
+ #endif
+
++#if defined(VGO_openbsd)
++/* -
++ File-descriptor tracking
++ -- */
++
++/* One of these is allocated for each open file descriptor. */
++typedef struct OpenFd
++{
++ Int fd;/* The file descriptor */
++ HChar *pathname; /* NULL if not a regular file or unknown */
++ struct OpenFd *next, *prev;
++} OpenFd;
++
++/* List of allocated file descriptors. */
++static OpenFd *opened_fds = NULL;
++
++/* Note the fact that a file descriptor was just closed. */
++static
++void delete_fd(Int fd)
++{
++ OpenFd *i = opened_fds;
++
++ while(i) {
++ if(i->fd == fd) {
++ if(i->prev)
++i->prev->next = i->next;
++ else
++opened_fds = i->next;
++ if(i->next)
++i->next->prev = i->prev;
++ if(i->pathname)
++VG_(arena_free) (VG_AR_CORE, i->pathname);
++ VG_(arena_free) (VG_AR_CORE, i);
++ break;
++ }
++ i = i->next;
++ }
++}
++
++/* Note the fact that a file descriptor was just opened. */
++static
++void register_fd(Int fd, const HChar *pathname)
++{
++ OpenFd *i;
++
++ /* Check to see if this fd is already open. */
++ i = opened_fds;
++ while (i) {
++ if (i->fd == fd) {
++ if (i->pathname) VG_(arena_free)(VG_AR_CORE, i->pathname);
++ break;
++ }
++ i = i->next;
++ }
++
++ /* Not already one: allocate an OpenFd */
++ if (i == NULL) {
++ i = VG_(arena_malloc)(VG_AR_CORE, "libcfile.regfd.1", sizeof(OpenFd));
++
++ i->prev = NULL;
++ i->next = opened_fds;
++ if(opened_fds) opened_fds->prev = i;
++ opened_fds = i;
++ }
++
++ i->fd = fd;
++ i->pathname = VG_(arena_strdup)(VG_AR_CORE, "libcfile.regfd.2", pathname);
++}
++
++extern char *VG_(pathname_by_fd)(Int);
++
++char *
++VG_(pathname_by_fd)(Int fd)
++{
++ OpenFd *a;
++
++ for (a = opened_fds; a; a = a->next) {
++ if (a->fd == fd && a->pathname)
++ return a->pathname;
++ }
++ return NULL;
++}
++#endif
++
+ SysRes VG_(open) ( const HChar* pathname, Int flags, Int mode )
+ {
+ # if
Re: Valgrind: patch to run Pthread target program
Sorry, From: Masato Asou Date: Mon, 09 Dec 2019 14:50:41 +0900 (JST) > Valgrind does not run Pthread target program. > I made patch to run Pthread target program. I forget increment REVISION in Makefile. -- ASOU Masato
Valgrind: patch to run Pthread target program
Hi, ports
Valgrind does not run Pthread target program.
I made patch to run Pthread target program.
I applied this patch and run attached main.c as:
$ cc main.c -lpthread
$ while :; do valgrind ./a.out 32 8; done
for 24 hours. I got no problem.
ok?
Index: patches/patch-coregrind_m_libcsignal_c
===
RCS file: patches/patch-coregrind_m_libcsignal_c
diff -N patches/patch-coregrind_m_libcsignal_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-coregrind_m_libcsignal_c 9 Dec 2019 05:30:18 -
@@ -0,0 +1,21 @@
+--- coregrind/m_libcsignal.c.orig
coregrind/m_libcsignal.c
+@@ -397,6 +397,7 @@
+ Int VG_(tkill)( Int lwpid, Int signo )
+ {
+ # if defined(__NR_tkill)
++ PRINT("sys___tfork ( %ld, %ld )",ARG1,ARG2);
+SysRes res = VG_(mk_SysRes_Error)(VKI_ENOSYS);
+res = VG_(do_syscall2)(__NR_tkill, lwpid, signo);
+if (sr_isError(res) && sr_Err(res) == VKI_ENOSYS)
+@@ -415,7 +416,9 @@
+return sr_isError(res) ? -1 : 0;
+
+ # elif defined(VGO_openbsd)
+- I_die_here;
++ SysRes res;
++ res = VG_(do_syscall3)(__NR_thrkill, lwpid, signo, NULL);
++ return sr_isError(res) ? -1 : 0;
+
+ # else
+ #error "Unsupported plat"
Index: patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h
===
RCS file:
/cvs/ports/devel/valgrind/patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h,v
retrieving revision 1.1
diff -u -p -r1.1 patch-coregrind_m_syswrap_priv_syswrap_openbsd_h
--- patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h23 Oct 2019
02:35:05 - 1.1
+++ patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h9 Dec 2019
05:30:18 -
@@ -1,5 +1,14 @@
--- coregrind/m_syswrap/priv_syswrap-openbsd.h.orig
+++ coregrind/m_syswrap/priv_syswrap-openbsd.h
+@@ -50,7 +50,7 @@
+ DECL_TEMPLATE(openbsd, sys_open);
+ DECL_TEMPLATE(openbsd, sys_close);
+ DECL_TEMPLATE(openbsd, sys_getentropy);
+-DECL_TEMPLATE(openbsd, sys___tfork);
++DECL_TEMPLATE(openbsd, sys___tfork_thread);
+ DECL_TEMPLATE(openbsd, sys_link);
+ DECL_TEMPLATE(openbsd, sys_unlink);
+ DECL_TEMPLATE(openbsd, sys_wait4);
@@ -144,6 +144,7 @@
DECL_TEMPLATE(openbsd, sys_pledge);
DECL_TEMPLATE(openbsd, sys_ppoll);
Index: patches/patch-coregrind_m_syswrap_syswrap_amd64_openbsd_c
===
RCS file: patches/patch-coregrind_m_syswrap_syswrap_amd64_openbsd_c
diff -N patches/patch-coregrind_m_syswrap_syswrap_amd64_openbsd_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-coregrind_m_syswrap_syswrap_amd64_openbsd_c 9 Dec 2019
05:30:18 -
@@ -0,0 +1,215 @@
+--- coregrind/m_syswrap/syswrap-amd64-openbsd.c.orig
coregrind/m_syswrap/syswrap-amd64-openbsd.c
+@@ -120,6 +120,212 @@
+ #define PRE(name) DEFN_PRE_TEMPLATE(openbsd, name)
+ #define POST(name) DEFN_POST_TEMPLATE(openbsd, name)
+
++extern UWord do_syscall_tfork_amd64_openbsd (
++Addr params,
++UWord psize,
++Addr startfunc,
++Addr startarg);
++asm(
++".text\n"
++".globl do_syscall_tfork_amd64_openbsd\n"
++"do_syscall_tfork_amd64_openbsd:\n"
++ /* Copy %rdx to %r8 and %rcx to %r9. See:
++ - lib/libc/arch/amd64/sys/tfork_thread.S */
++" movq%rdx, %r8\n"
++" movq%rcx, %r9\n"
++" movq$8, %rax\n" /* syscall_no */
++" syscall\n"
++" jb 5f\n" /* error */
++ /*
++ * Check to see if we are in the parent or child
++ */
++" cmpl$0, %eax\n"
++" jz 4f\n" /* child */
++" jmp 5f\n" /* parent */
++ /* the retpoline we'll use to call the child's main */
++".align 16, 0xcc\n" /* _ALIGN_TRAPS */
++"1:\n"/* JMP_RETPOLINE(r8) --> */
++" call3f\n"
++"2: pause\n"
++" lfence\n"
++" jmp 2b\n"
++".align 16, 0xcc\n" /* _ALIGN_TRAPS */
++"3: mov %r8,(%rsp)\n"
++" ret\n"
++ /* JMP_RETPOLINE(r8) <-- */
++ /*
++ * If we are in the child (new thread), then
++ * set-up the call to the internal subroutine. If it
++ * returns, then call __threxit.
++ */
++".align 16, 0xcc\n" /* _ALIGN_TRAPS */
++"4:\n"
++" movq%r9, %rdi\n"
++" call1b\n"
++ /*
++ * Thread exit system call
++ */
++" movl$302, %eax\n" /* 302 == SYS___threxit */
++" xorl%edi, %edi\n"
++" syscall\n"
++ /*NOTREACHED*/
++"5:\n"/* parent or error */
++" ret\n"
++".previous\n"
++);
++
++static void setup_child ( ThreadArchState*, ThreadArchState* );
++
++void setup_child ( /*OUT*/ ThreadArchState *child,
++ /*IN*/ ThreadArchState *parent )
++{
++ /* We inherit
Re: Valgrind: Delete 'USE_WXNEEDED = Yes' from Makefile
Sorry,
I was committed below.
I lost OK rsadowski@.
--
ASOU Masato
> CVSROOT: /cvs
> Module name: ports
> Changes by: a...@cvs.openbsd.org2019/11/05 22:25:13
>
> Modified files:
>devel/valgrind : Makefile
>devel/valgrind/patches:
>patch-coregrind_link_tool_exe_openbsd_in
>patch-coregrind_m_aspacemgr_aspacemgr-linux_c
>patch-coregrind_m_initimg_initimg-openbsd_c
>patch-coregrind_m_transtab_c
> Added files:
> devel/valgrind/patches: patch-coregrind_m_mallocfree_c
> Removed files:
> devel/valgrind/patches:
>patch-coregrind_m_scheduler_scheduler_c
>patch-coregrind_pub_core_transtab_h
>
> Log message:
> Delete mmap(PROT_WRITE) from the memory area of the execution code of the
> target program.
From: Rafael Sadowski
Subject: Re: Valgrind: Delete 'USE_WXNEEDED = Yes' from Makefile
Date: Tue, 5 Nov 2019 16:19:54 +0100
> On Mon Oct 28, 2019 at 11:36:47AM +0900, Masato Asou wrote:
>> From: Masato Asou
>> Subject: Valgrind: Delete 'USE_WXNEEDED = Yes' from Makefile
>> Date: Fri, 25 Oct 2019 16:40:43 +0900 (JST)
>>
>> > Hi ports,
>> >
>> > The Valgrind specifies 'READ | WRITE | EXEC' when allocating memory
>> > for target program as follows:
>> >
>> > int fd = open("a.out", O_RDONLY);
>> > void *addr = mmap(..., prot = PROT_READ | PROT_WRITE | PROT_EXEC, ...);
>> > read(fd, addr, LENGTH);
>> > /* Execute target program */
>> >
>> > I modified to specify 'READ | EXEC' after readind the target
>> > program as folloes:
>> >
>> > int fd = open("a.out", O_RDONLY);
>> > void *addr = mmap(..., prot = PROT_READ | PROT_WRITE, ...);
>> > read(fd, addr, LENGTH);
>> > mmap(addr, LENGTH, prot = PROT_READ | PROT_EXEC, ...);
>> > /* Execute target program */
>> >
>> > Therefor, the target program area can not be rewritten.
>> >
>> > How about it?
>>
>> Sorry, I lost increment RESISION.
>
> Compiles and runs fine on amd64. OK rsadowski@
>
>> --
>> ASOU Masato
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/devel/valgrind/Makefile,v
>> retrieving revision 1.21
>> diff -u -p -r1.21 Makefile
>> --- Makefile 23 Oct 2019 02:35:05 - 1.21
>> +++ Makefile 28 Oct 2019 02:10:39 -
>> @@ -1,7 +1,5 @@
>> # $OpenBSD: Makefile,v 1.21 2019/10/23 02:35:05 asou Exp $
>>
>> -USE_WXNEEDED = Yes
>> -
>> ONLY_FOR_ARCHS =amd64
>>
>> COMMENT = instrumentation framework for dynamic analysis tools
>> @@ -9,7 +7,7 @@ CATEGORIES = devel
>>
>> V = 3.10.1
>> PV =20160331
>> -REVISION = 14
>> +REVISION = 15
>> DISTNAME = valgrind-${V}
>> EXTRACT_SUFX = .tar.bz2
>>
>> Index: patches/patch-coregrind_link_tool_exe_openbsd_in
>> ===
>> RCS file:
>> /cvs/ports/devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in,v
>> retrieving revision 1.3
>> diff -u -p -r1.3 patch-coregrind_link_tool_exe_openbsd_in
>> --- patches/patch-coregrind_link_tool_exe_openbsd_in 2 Oct 2019 17:19:29
>> - 1.3
>> +++ patches/patch-coregrind_link_tool_exe_openbsd_in 28 Oct 2019 02:10:39
>> -
>> @@ -5,12 +5,12 @@
>> system(sprintf "sed -e 's|%x|%x|g' < $ldscript > $temp", $origbase,
>> $notebase);
>>
>> -my $cmd = sprintf "$cc -static -nopie -Wl,-Ttext=0x%x -Wl,-T,$temp",
>> $textbase;
>> -+my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-zwxneeded
>> -Wl,-Ttext=0x%x -Wl,-T,$temp", $textbase;
>> +# XXX The '-s' option was not specified when executing the install command.
>> +# Instead '--strip-all' is now executed at link time.
>> +# strip command rewrite offset and align in ELF file. Therefor, when
>> valgrind
>> +# launch memcheck-amd64-openbsd, an Abort trap occurs in the execvp()
>> system
>> +# call.
>> ++my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-Ttext=0x%x
>> -Wl,-T,$temp", $textbase;
>>
>> # Add the rest of the parameters
>> foreach my $n (2 .. $#ARGV) {
>> Index: patches/patch-coregrind_m_aspacemgr_aspacemgr-linux_c
>>
Valgrind: Delete 'USE_WXNEEDED = Yes' from Makefile
Hi ports,
The Valgrind specifies 'READ | WRITE | EXEC' when allocating memory
for target program as follows:
int fd = open("a.out", O_RDONLY);
void *addr = mmap(..., prot = PROT_READ | PROT_WRITE | PROT_EXEC, ...);
read(fd, addr, LENGTH);
/* Execute target program */
I modified to specify 'READ | EXEC' after readind the target
program as folloes:
int fd = open("a.out", O_RDONLY);
void *addr = mmap(..., prot = PROT_READ | PROT_WRITE, ...);
read(fd, addr, LENGTH);
mmap(addr, LENGTH, prot = PROT_READ | PROT_EXEC, ...);
/* Execute target program */
Therefor, the target program area can not be rewritten.
How about it?
--
ASOU Masato
Index: Makefile
===
RCS file: /cvs/ports/devel/valgrind/Makefile,v
retrieving revision 1.21
diff -u -p -r1.21 Makefile
--- Makefile23 Oct 2019 02:35:05 - 1.21
+++ Makefile25 Oct 2019 04:23:10 -
@@ -1,7 +1,5 @@
# $OpenBSD: Makefile,v 1.21 2019/10/23 02:35:05 asou Exp $
-USE_WXNEEDED = Yes
-
ONLY_FOR_ARCHS = amd64
COMMENT = instrumentation framework for dynamic analysis tools
Index: patches/patch-coregrind_link_tool_exe_openbsd_in
===
RCS file:
/cvs/ports/devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in,v
retrieving revision 1.3
diff -u -p -r1.3 patch-coregrind_link_tool_exe_openbsd_in
--- patches/patch-coregrind_link_tool_exe_openbsd_in2 Oct 2019 17:19:29
- 1.3
+++ patches/patch-coregrind_link_tool_exe_openbsd_in25 Oct 2019 04:23:10
-
@@ -5,12 +5,12 @@
system(sprintf "sed -e 's|%x|%x|g' < $ldscript > $temp", $origbase,
$notebase);
-my $cmd = sprintf "$cc -static -nopie -Wl,-Ttext=0x%x -Wl,-T,$temp",
$textbase;
-+my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-zwxneeded
-Wl,-Ttext=0x%x -Wl,-T,$temp", $textbase;
+# XXX The '-s' option was not specified when executing the install command.
+# Instead '--strip-all' is now executed at link time.
+# strip command rewrite offset and align in ELF file. Therefor, when valgrind
+# launch memcheck-amd64-openbsd, an Abort trap occurs in the execvp() system
+# call.
++my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-Ttext=0x%x
-Wl,-T,$temp", $textbase;
# Add the rest of the parameters
foreach my $n (2 .. $#ARGV) {
Index: patches/patch-coregrind_m_aspacemgr_aspacemgr-linux_c
===
RCS file:
/cvs/ports/devel/valgrind/patches/patch-coregrind_m_aspacemgr_aspacemgr-linux_c,v
retrieving revision 1.1
diff -u -p -r1.1 patch-coregrind_m_aspacemgr_aspacemgr-linux_c
--- patches/patch-coregrind_m_aspacemgr_aspacemgr-linux_c 2 Oct 2019
17:19:29 - 1.1
+++ patches/patch-coregrind_m_aspacemgr_aspacemgr-linux_c 25 Oct 2019
04:23:10 -
@@ -1,5 +1,17 @@
--- coregrind/m_aspacemgr/aspacemgr-linux.c.orig
+++ coregrind/m_aspacemgr/aspacemgr-linux.c
+@@ -2498,7 +2498,11 @@
+ a client request to call the outer VG_(am_get_advisory). */
+sres = VG_(am_do_mmap_NO_NOTIFY)(
+ advised, length,
++#if defined(__OpenBSD__)
++ VKI_PROT_READ|VKI_PROT_WRITE,
++#else
+ VKI_PROT_READ|VKI_PROT_WRITE|VKI_PROT_EXEC,
++#endif
+ VKI_MAP_FIXED|VKI_MAP_PRIVATE|VKI_MAP_ANONYMOUS,
+ VM_TAG_VALGRIND, 0
+ );
@@ -2543,6 +2543,54 @@ SysRes VG_(am_mmap_anon_float_valgrind)( SizeT length )
return sres;
}
@@ -30,7 +42,7 @@
+ any resulting failure immediately. */
+ sres = VG_(am_do_mmap_NO_NOTIFY)(
+ advised, length,
-+ VKI_PROT_READ|VKI_PROT_WRITE|VKI_PROT_EXEC,
++ VKI_PROT_READ|VKI_PROT_WRITE,
+ VKI_MAP_PRIVATE|VKI_MAP_ANONYMOUS|VKI_MAP_STACK,
+ VM_TAG_VALGRIND, 0
+ );
Index: patches/patch-coregrind_m_initimg_initimg-openbsd_c
===
RCS file:
/cvs/ports/devel/valgrind/patches/patch-coregrind_m_initimg_initimg-openbsd_c,v
retrieving revision 1.1
diff -u -p -r1.1 patch-coregrind_m_initimg_initimg-openbsd_c
--- patches/patch-coregrind_m_initimg_initimg-openbsd_c 4 Feb 2019 23:34:10
- 1.1
+++ patches/patch-coregrind_m_initimg_initimg-openbsd_c 25 Oct 2019 04:23:10
-
@@ -12,3 +12,21 @@ Index: coregrind/m_initimg/initimg-openb
/* --- !!! --- EXTERNAL HEADERS end --- !!! --- */
+@@ -575,7 +575,7 @@
+ res = VG_(am_mmap_anon_fixed_client)(
+ anon_start -inner_HACK,
+ anon_size +inner_HACK,
+- VKI_PROT_READ|VKI_PROT_WRITE|VKI_PROT_EXEC
++ VKI_PROT_READ|VKI_PROT_WRITE
+ );
+ }
+ if ((!ok) || sr_isError(res)) {
+@@ -758,7 +758,7 @@
+sres = VG_(am_mmap_anon_fixed_client)(
+ anon_start,
+ anon_size,
+-
Re: valgrind diff to fix run memcheck on amd64
Sorry, From: Stuart Henderson Date: Fri, 18 Oct 2019 21:58:25 +0100 > On 2019/10/18 15:08, Masato Asou wrote: >> From: YASUOKA Masahiko >> Date: Wed, 02 Oct 2019 23:29:05 +0900 (JST) >> >> > I looked into the problem more. >> > >> > - unveil(2) itself fails >> > - so file system related system calls are not restricted (yet) >> > >> > valgrind complains: >> > >> > ==13326== >> > --13326-- WARNING: unhandled syscall: 114 >> > --13326-- You may be able to write your own handler. >> > --13326-- Read the file README_MISSING_SYSCALL_OR_IOCTL. >> > --13326-- Nevertheless we consider this a bug. Please report >> > --13326-- it at http://valgrind.org/support/bug_reports.html. >> > >> > valgrind doesn't support unveil(2) yet. I suppose Asou can add that. >> >> I was added unveil(2). > > Please set REVISION = 14 in ports/devel/valgrind/Makefile so that > "pkg_add -u" will find the update. > > Otherwise OK sthen@ I was commited below: > List: openbsd-ports-cvs > Subject:CVS: cvs.openbsd.org: ports > From: ASOU Masato > Date: 2019-10-23 2:35:06 > Message-ID: 3b1cd636a5f50760 () openbsd ! org > [Download RAW message or body] > > CVSROOT: /cvs > Module name: ports > Changes by: a...@cvs.openbsd.org2019/10/22 20:35:05 > > Modified files: > devel/valgrind : Makefile > Added files: > devel/valgrind/patches: > > patch-coregrind_m_syswrap_priv_syswrap_openbsd_h > patch-coregrind_m_syswrap_syswrap_openbsd_c > patch-include_vki_vki_scnums_openbsd_h > > Log message: > Add sys_unveil() I lost 'ok sthen@'. -- ASOU Masato
Re: valgrind diff to fix run memcheck on amd64
From: Stuart Henderson
Subject: Re: valgrind diff to fix run memcheck on amd64
Date: Fri, 18 Oct 2019 21:58:25 +0100
> On 2019/10/18 15:08, Masato Asou wrote:
>> From: YASUOKA Masahiko
>> Date: Wed, 02 Oct 2019 23:29:05 +0900 (JST)
>>
>> > I looked into the problem more.
>> >
>> > - unveil(2) itself fails
>> > - so file system related system calls are not restricted (yet)
>> >
>> > valgrind complains:
>> >
>> > ==13326==
>> > --13326-- WARNING: unhandled syscall: 114
>> > --13326-- You may be able to write your own handler.
>> > --13326-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
>> > --13326-- Nevertheless we consider this a bug. Please report
>> > --13326-- it at http://valgrind.org/support/bug_reports.html.
>> >
>> > valgrind doesn't support unveil(2) yet. I suppose Asou can add that.
>>
>> I was added unveil(2).
>
> Please set REVISION = 14 in ports/devel/valgrind/Makefile so that
> "pkg_add -u" will find the update.
>
> Otherwise OK sthen@
Modified REVISION.
--
ASOU Masato
Index: Makefile
===
RCS file: /cvs/ports/devel/valgrind/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- Makefile2 Oct 2019 17:19:29 - 1.20
+++ Makefile21 Oct 2019 01:58:47 -
@@ -9,7 +9,7 @@ CATEGORIES =devel
V =3.10.1
PV = 20160331
-REVISION = 13
+REVISION = 14
DISTNAME = valgrind-${V}
EXTRACT_SUFX = .tar.bz2
Index: patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h
===
RCS file: patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h
diff -N patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h21 Oct 2019
01:58:47 -
@@ -0,0 +1,10 @@
+--- coregrind/m_syswrap/priv_syswrap-openbsd.h.orig
coregrind/m_syswrap/priv_syswrap-openbsd.h
+@@ -144,6 +144,7 @@
+ DECL_TEMPLATE(openbsd, sys_pledge);
+ DECL_TEMPLATE(openbsd, sys_ppoll);
+ DECL_TEMPLATE(openbsd, sys_pselect);
++DECL_TEMPLATE(openbsd, sys_unveil);
+ DECL_TEMPLATE(openbsd, sys_sigsuspend);
+ DECL_TEMPLATE(openbsd, sys_gettimeofday);
+ DECL_TEMPLATE(openbsd, sys_getrusage);
Index: patches/patch-coregrind_m_syswrap_syswrap_openbsd_c
===
RCS file: patches/patch-coregrind_m_syswrap_syswrap_openbsd_c
diff -N patches/patch-coregrind_m_syswrap_syswrap_openbsd_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-coregrind_m_syswrap_syswrap_openbsd_c 21 Oct 2019 01:58:47
-
@@ -0,0 +1,30 @@
+--- coregrind/m_syswrap/syswrap-openbsd.c.orig
coregrind/m_syswrap/syswrap-openbsd.c
+@@ -575,6 +579,17 @@
+ // XXXTBD
+ }
+
++PRE(sys_unveil)
++{
++ PRINT("sys_unveil ( %#lx(%s), %#lx(%s) )",
++ ARG1,(char *)ARG1,ARG2,(char*)ARG2);
++ PRE_REG_READ2(long, "unveil", const char *, path, const char *,
permissions);
++ if (ARG1 != (UWord)NULL)
++ PRE_MEM_RASCIIZ( "unveil(path)", ARG1 );
++ if (ARG2 != (UWord)NULL)
++ PRE_MEM_RASCIIZ( "unveil(permissions)", ARG2 );
++}
++
+ PRE(sys_getsockname)
+ {
+PRINT("sys_getsockname ( %ld, %#lx, %#lx )",ARG1,ARG2,ARG3);
+@@ -4079,7 +4093,7 @@
+ BSDX_(__NR_sigsuspend, sys_sigsuspend),// 111
+ BSDX_(__NR_sendsyslog, sys_sendsyslog),// 112
+ // obsol orecvmsg // 113
+- // obsol osendmsg // 114
++ BSDX_(__NR_unveil, sys_unveil),// 114
+ // obsol vtrace // 115
+
+ BSDX_(__NR_getsockopt, sys_getsockopt),// 118
+Only in pobj/valgrind-3.10.1/valgrind-3.10.1/coregrind/m_syswrap:
syswrap-openbsd.c.orig
Index: patches/patch-include_vki_vki_scnums_openbsd_h
===
RCS file: patches/patch-include_vki_vki_scnums_openbsd_h
diff -N patches/patch-include_vki_vki_scnums_openbsd_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-include_vki_vki_scnums_openbsd_h 21 Oct 2019 01:58:47
-
@@ -0,0 +1,10 @@
+--- include/vki/vki-scnums-openbsd.h.orig
include/vki/vki-scnums-openbsd.h
+@@ -146,6 +146,7 @@
+ #define __NR_pselect110
+ #define __NR_sigsuspend 111
+ #define __NR_sendsyslog 112
++#define __NR_unveil 114
+ #define __NR_getsockopt 118
+ #define __NR_thrkill119
+ #define __NR_readv 120
Re: valgrind diff to fix run memcheck on amd64
From: YASUOKA Masahiko
Date: Wed, 02 Oct 2019 23:29:05 +0900 (JST)
> I looked into the problem more.
>
> - unveil(2) itself fails
> - so file system related system calls are not restricted (yet)
>
> valgrind complains:
>
> ==13326==
> --13326-- WARNING: unhandled syscall: 114
> --13326-- You may be able to write your own handler.
> --13326-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
> --13326-- Nevertheless we consider this a bug. Please report
> --13326-- it at http://valgrind.org/support/bug_reports.html.
>
> valgrind doesn't support unveil(2) yet. I suppose Asou can add that.
I was added unveil(2).
--
ASOU Masato
Index: patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h
===
RCS file: patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h
diff -N patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h8 Oct 2019
02:53:32 -
@@ -0,0 +1,10 @@
+--- coregrind/m_syswrap/priv_syswrap-openbsd.h.orig
coregrind/m_syswrap/priv_syswrap-openbsd.h
+@@ -144,6 +144,7 @@
+ DECL_TEMPLATE(openbsd, sys_pledge);
+ DECL_TEMPLATE(openbsd, sys_ppoll);
+ DECL_TEMPLATE(openbsd, sys_pselect);
++DECL_TEMPLATE(openbsd, sys_unveil);
+ DECL_TEMPLATE(openbsd, sys_sigsuspend);
+ DECL_TEMPLATE(openbsd, sys_gettimeofday);
+ DECL_TEMPLATE(openbsd, sys_getrusage);
Index: patches/patch-coregrind_m_syswrap_syswrap_openbsd_c
===
RCS file: patches/patch-coregrind_m_syswrap_syswrap_openbsd_c
diff -N patches/patch-coregrind_m_syswrap_syswrap_openbsd_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-coregrind_m_syswrap_syswrap_openbsd_c 8 Oct 2019 02:53:32
-
@@ -0,0 +1,30 @@
+--- coregrind/m_syswrap/syswrap-openbsd.c.orig
coregrind/m_syswrap/syswrap-openbsd.c
+@@ -575,6 +579,17 @@
+ // XXXTBD
+ }
+
++PRE(sys_unveil)
++{
++ PRINT("sys_unveil ( %#lx(%s), %#lx(%s) )",
++ ARG1,(char *)ARG1,ARG2,(char*)ARG2);
++ PRE_REG_READ2(long, "unveil", const char *, path, const char *,
permissions);
++ if (ARG1 != (UWord)NULL)
++ PRE_MEM_RASCIIZ( "unveil(path)", ARG1 );
++ if (ARG2 != (UWord)NULL)
++ PRE_MEM_RASCIIZ( "unveil(permissions)", ARG2 );
++}
++
+ PRE(sys_getsockname)
+ {
+PRINT("sys_getsockname ( %ld, %#lx, %#lx )",ARG1,ARG2,ARG3);
+@@ -4079,7 +4093,7 @@
+ BSDX_(__NR_sigsuspend, sys_sigsuspend),// 111
+ BSDX_(__NR_sendsyslog, sys_sendsyslog),// 112
+ // obsol orecvmsg // 113
+- // obsol osendmsg // 114
++ BSDX_(__NR_unveil, sys_unveil),// 114
+ // obsol vtrace // 115
+
+ BSDX_(__NR_getsockopt, sys_getsockopt),// 118
+Only in pobj/valgrind-3.10.1/valgrind-3.10.1/coregrind/m_syswrap:
syswrap-openbsd.c.orig
Index: patches/patch-include_vki_vki_scnums_openbsd_h
===
RCS file: patches/patch-include_vki_vki_scnums_openbsd_h
diff -N patches/patch-include_vki_vki_scnums_openbsd_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-include_vki_vki_scnums_openbsd_h 8 Oct 2019 02:53:32
-
@@ -0,0 +1,10 @@
+--- include/vki/vki-scnums-openbsd.h.orig
include/vki/vki-scnums-openbsd.h
+@@ -146,6 +146,7 @@
+ #define __NR_pselect110
+ #define __NR_sigsuspend 111
+ #define __NR_sendsyslog 112
++#define __NR_unveil 114
+ #define __NR_getsockopt 118
+ #define __NR_thrkill119
+ #define __NR_readv 120
Re: valgrind diff to fix run memcheck on amd64
Sorry, my delayed reply. From: YASUOKA Masahiko Date: Wed, 02 Oct 2019 23:29:05 +0900 (JST) > I looked into the problem more. > > - unveil(2) itself fails > - so file system related system calls are not restricted (yet) > > valgrind complains: > > ==13326== > --13326-- WARNING: unhandled syscall: 114 > --13326-- You may be able to write your own handler. > --13326-- Read the file README_MISSING_SYSCALL_OR_IOCTL. > --13326-- Nevertheless we consider this a bug. Please report > --13326-- it at http://valgrind.org/support/bug_reports.html. > > valgrind doesn't support unveil(2) yet. I suppose Asou can add that. Now I am fixing this problem. -- ASOU Masato
Re: valgrind diff to fix run memcheck on amd64
From: Masato Asou
Date: Fri, 27 Sep 2019 13:18:50 +0900 (JST)
> Hi ports,
>
> This is a patch for running valgrind memcheck on amd64. I corrected
> the following two problems.
>
> - FS register can be used.
> - Fixed a problem that strip command rewrites offset and align of
> memcheck ELF file.
Additional information:
- Abort trap was occurred when lounched valgrind.
$ cd /usr/ports/devel/valgrind
$ make && doas make install
$ valgrind /bin/ls
Abort trap
$
Sorry, I lost --strip-all option into
coregrind/link_tool_exe_openbsd.in.
New patch is below:
Index: Makefile
===
RCS file: /cvs/ports/devel/valgrind/Makefile,v
retrieving revision 1.19
diff -u -p -r1.19 Makefile
--- Makefile12 Jul 2019 20:46:03 - 1.19
+++ Makefile27 Sep 2019 03:08:46 -
@@ -38,4 +38,10 @@ AUTORECONF = /bin/sh ./autogen.sh
.if ${PROPERTIES:Mclang}
# replace -lgcc
MAKE_FLAGS = TOOL_LDADD_COMMON=-lcompiler_rt
+# XXX The '-s' option was not specified when executing the install command.
+# Instead '--strip-all' is now executed at link time.
+# strip command rewrite offset and align in ELF file. Therefor, when valgrind
+# launch memcheck-amd64-openbsd, an Abort trap occurs in the execvp() system
+# call.
+INSTALL_STRIP =
.endif
Index: patches/patch-VEX_priv_guest_amd64_helpers_c
===
RCS file: patches/patch-VEX_priv_guest_amd64_helpers_c
diff -N patches/patch-VEX_priv_guest_amd64_helpers_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-VEX_priv_guest_amd64_helpers_c27 Sep 2019 03:08:46
-
@@ -0,0 +1,16 @@
+--- VEX/priv/guest_amd64_helpers.c.orig
VEX/priv/guest_amd64_helpers.c
+@@ -3744,6 +3744,13 @@ void LibVEX_GuestAMD64_initialise (
/*OUT*/VexGuestAMD64State* vex_state )
+/* HACK: represent the offset associated with %fs==0. This
+ assumes that %fs is only ever zero. */
+vex_state->guest_FS_ZERO = 0;
++#if defined(__OpenBSD__)
++{
++ int fs;
++ __asm__("mov %%fs,%0" : "=r" (fs));
++ vex_state->guest_FS_ZERO = fs;
++}
++#endif
+
+vex_state->guest_RIP = 0;
+
Index: patches/patch-VEX_priv_guest_amd64_toIR_c
===
RCS file: patches/patch-VEX_priv_guest_amd64_toIR_c
diff -N patches/patch-VEX_priv_guest_amd64_toIR_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-VEX_priv_guest_amd64_toIR_c 27 Sep 2019 03:08:46 -
@@ -0,0 +1,205 @@
+--- VEX/priv/guest_amd64_toIR.c.orig
VEX/priv/guest_amd64_toIR.c
+@@ -312,7 +312,11 @@ static IROp mkSizedOp ( IRType ty, IROp op8 )
+|| op8 == Iop_Shl8 || op8 == Iop_Shr8 || op8 == Iop_Sar8
+|| op8 == Iop_CmpEQ8 || op8 == Iop_CmpNE8
+|| op8 == Iop_CasCmpNE8
++#if !defined(__OpenBSD__)
+|| op8 == Iop_Not8 );
++#else
++ || op8 == Iop_Not8 || op8 == Iop_MovFromSeg8);
++#endif
+switch (ty) {
+ case Ity_I8: return 0 +op8;
+ case Ity_I16: return 1 +op8;
+@@ -709,6 +713,12 @@ static Bool haveF3 ( Prefix pfx ) {
+return toBool((pfx & PFX_F3) > 0);
+ }
+
++#if defined(__OpenBSD__)
++static Bool haveFS( Prefix pfx ) {
++ return toBool((pfx & PFX_FS) > 0);
++}
++#endif
++
+ static Bool have66 ( Prefix pfx ) {
+return toBool((pfx & PFX_66) > 0);
+ }
+@@ -1213,7 +1223,6 @@ static void putIRegRexB ( Int sz, Prefix pfx, UInt
lo3bits, IRExpr* e )
+));
+ }
+
+-
+ /* Functions for getting register numbers from modrm bytes and REX
+when we don't have to consider the complexities of integer subreg
+accesses.
+@@ -3137,6 +3146,136 @@ ULong dis_op2_G_E ( VexAbiInfo* vbi,
+ }
+
+
++#if defined(__OpenBSD__)
++/* Handle binary integer instructions of the form
++ op S, G, E meaning
++ op segment reg, reg, reg
++ Is passed the a ptr to the modRM byte, the actual operation, and the
++ data size. Returns the address advanced completely over this
++ instruction.
++
++ S(segment) is reg.
++ G(src) is reg.
++
++ OP %S:%G, tmp
++ PUT tmp, %E
++*/
++static
++Int dis_op3_S_G_E ( VexAbiInfo* vbi,
++Prefix pfx,
++IROpop,
++Int size,
++Longdelta0,
++/*OUT*/HChar* buf)
++{
++ IRType ty= szToITy(size);
++ IRTemp dst1 = newTemp(ty);
++ IRTemp off = newTemp(ty);
++ IRTemp dst0 = newTemp(ty);
++ Long delta = delta0;
++ UChar modrm = getUChar(delta0++);
++ UChar rm= (modrm & 7);
++
++ assign(dst0, getIRegG(size, pfx, modrm));
++ assign(off, getIRegE(size, pfx, modrm | 0xc0));
++ assign(dst1, binop(op, mkexpr(dst0), mkexpr(off)));
++ putIRegG(size, pfx, modrm, mkexpr(dst1));
++
++ if (rm == 0x4) {
++ UChar tmp = getUChar(delta0++);
++
valgrind diff to fix run memcheck on amd64
Hi ports,
This is a patch for running valgrind memcheck on amd64. I corrected
the following two problems.
- FS register can be used.
- Fixed a problem that strip command rewrites offset and align of
memcheck ELF file.
Index: Makefile
===
RCS file: /cvs/ports/devel/valgrind/Makefile,v
retrieving revision 1.19
diff -u -p -r1.19 Makefile
--- Makefile12 Jul 2019 20:46:03 - 1.19
+++ Makefile27 Sep 2019 03:08:46 -
@@ -38,4 +38,10 @@ AUTORECONF = /bin/sh ./autogen.sh
.if ${PROPERTIES:Mclang}
# replace -lgcc
MAKE_FLAGS = TOOL_LDADD_COMMON=-lcompiler_rt
+# XXX The '-s' option was not specified when executing the install command.
+# Instead '--strip-all' is now executed at link time.
+# strip command rewrite offset and align in ELF file. Therefor, when valgrind
+# launch memcheck-amd64-openbsd, an Abort trap occurs in the execvp() system
+# call.
+INSTALL_STRIP =
.endif
Index: patches/patch-VEX_priv_guest_amd64_helpers_c
===
RCS file: patches/patch-VEX_priv_guest_amd64_helpers_c
diff -N patches/patch-VEX_priv_guest_amd64_helpers_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-VEX_priv_guest_amd64_helpers_c27 Sep 2019 03:08:46
-
@@ -0,0 +1,16 @@
+--- VEX/priv/guest_amd64_helpers.c.orig
VEX/priv/guest_amd64_helpers.c
+@@ -3744,6 +3744,13 @@ void LibVEX_GuestAMD64_initialise (
/*OUT*/VexGuestAMD64State* vex_state )
+/* HACK: represent the offset associated with %fs==0. This
+ assumes that %fs is only ever zero. */
+vex_state->guest_FS_ZERO = 0;
++#if defined(__OpenBSD__)
++{
++ int fs;
++ __asm__("mov %%fs,%0" : "=r" (fs));
++ vex_state->guest_FS_ZERO = fs;
++}
++#endif
+
+vex_state->guest_RIP = 0;
+
Index: patches/patch-VEX_priv_guest_amd64_toIR_c
===
RCS file: patches/patch-VEX_priv_guest_amd64_toIR_c
diff -N patches/patch-VEX_priv_guest_amd64_toIR_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-VEX_priv_guest_amd64_toIR_c 27 Sep 2019 03:08:46 -
@@ -0,0 +1,205 @@
+--- VEX/priv/guest_amd64_toIR.c.orig
VEX/priv/guest_amd64_toIR.c
+@@ -312,7 +312,11 @@ static IROp mkSizedOp ( IRType ty, IROp op8 )
+|| op8 == Iop_Shl8 || op8 == Iop_Shr8 || op8 == Iop_Sar8
+|| op8 == Iop_CmpEQ8 || op8 == Iop_CmpNE8
+|| op8 == Iop_CasCmpNE8
++#if !defined(__OpenBSD__)
+|| op8 == Iop_Not8 );
++#else
++ || op8 == Iop_Not8 || op8 == Iop_MovFromSeg8);
++#endif
+switch (ty) {
+ case Ity_I8: return 0 +op8;
+ case Ity_I16: return 1 +op8;
+@@ -709,6 +713,12 @@ static Bool haveF3 ( Prefix pfx ) {
+return toBool((pfx & PFX_F3) > 0);
+ }
+
++#if defined(__OpenBSD__)
++static Bool haveFS( Prefix pfx ) {
++ return toBool((pfx & PFX_FS) > 0);
++}
++#endif
++
+ static Bool have66 ( Prefix pfx ) {
+return toBool((pfx & PFX_66) > 0);
+ }
+@@ -1213,7 +1223,6 @@ static void putIRegRexB ( Int sz, Prefix pfx, UInt
lo3bits, IRExpr* e )
+));
+ }
+
+-
+ /* Functions for getting register numbers from modrm bytes and REX
+when we don't have to consider the complexities of integer subreg
+accesses.
+@@ -3137,6 +3146,136 @@ ULong dis_op2_G_E ( VexAbiInfo* vbi,
+ }
+
+
++#if defined(__OpenBSD__)
++/* Handle binary integer instructions of the form
++ op S, G, E meaning
++ op segment reg, reg, reg
++ Is passed the a ptr to the modRM byte, the actual operation, and the
++ data size. Returns the address advanced completely over this
++ instruction.
++
++ S(segment) is reg.
++ G(src) is reg.
++
++ OP %S:%G, tmp
++ PUT tmp, %E
++*/
++static
++Int dis_op3_S_G_E ( VexAbiInfo* vbi,
++Prefix pfx,
++IROpop,
++Int size,
++Longdelta0,
++/*OUT*/HChar* buf)
++{
++ IRType ty= szToITy(size);
++ IRTemp dst1 = newTemp(ty);
++ IRTemp off = newTemp(ty);
++ IRTemp dst0 = newTemp(ty);
++ Long delta = delta0;
++ UChar modrm = getUChar(delta0++);
++ UChar rm= (modrm & 7);
++
++ assign(dst0, getIRegG(size, pfx, modrm));
++ assign(off, getIRegE(size, pfx, modrm | 0xc0));
++ assign(dst1, binop(op, mkexpr(dst0), mkexpr(off)));
++ putIRegG(size, pfx, modrm, mkexpr(dst1));
++
++ if (rm == 0x4) {
++ UChar tmp = getUChar(delta0++);
++ vassert(tmp == 0x24);
++ } else if (rm == 0x05) {
++ UChar tmp = getUChar(delta0++);
++ vassert(tmp == 0x00);
++ }
++
++ DIS(buf, "%s(%s)", segRegTxt(pfx),
++ nameIRegRexB(haveASO(pfx) ? 4 : 8, pfx, rm));
++
++ return delta0 - delta;
++}
++
++static void
++dis_op3_assignDst(IROp op, Int size, IRTemp src, IRTemp dst, IRTemp off)
++{
++ switch (size) {
++ case 4: {
++ IRTemp src1 = newTemp(szToITy(8));
