Hi,
On Sat, Mar 8, 2025 at 6:09 PM Landry Breuil wrote:
>
> hi,
>
> apparently valgrind is broken at runtime:
>
> $valgrind
> memcheck-amd64-openbsd[23142]: pinsyscalls addr 3806a478 code 20, pinoff
> 0x (pin 0 0-0 0) (libcpin 0 0-0 0) error 78
> Abort trap (
hi,
apparently valgrind is broken at runtime:
$valgrind
memcheck-amd64-openbsd[23142]: pinsyscalls addr 3806a478 code 20, pinoff
0x (pin 0 0-0 0) (libcpin 0 0-0 0) error 78
Abort trap (core dumped)
should we mark it as such in the port for 7.7 ?
Landry
On Fri, Nov 17, 2023 at 03:04:02PM +0900, ASOU Masato wrote:
> ping
>
> I confermed the operation using snapshot created onfNovember 16th.
> --
> ASOU Masato
>
> -- Forwarded message -
> From: 朝生正人
> Date: 2023年11月2日(木) 10:45
> Subject: devel/val
ping
I confermed the operation using snapshot created onfNovember 16th.
--
ASOU Masato
-- Forwarded message -
From: 朝生正人
Date: 2023年11月2日(木) 10:45
Subject: devel/valgrind: removal syscall(2)
To:
I have moved my email address from a...@soum.co.jp to
takeasou.mas...@gmail.com
dio/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
>>
3949==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' fil
tdio/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
rom: 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
>
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 n
: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
On Tue, Sep 05, 2023 at 03:00:12PM +0900, Masato Asou wrote:
> 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. T
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.
>>
>> comm
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
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
On 2023/08/04 08:14:37 +0900, Masato Asou wrote:
> >>> 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 l
OK op@.
>>> >
>>> > I still get some ??? entries, for example with grep:
>>> >
>>> > $ make clean obj
>>> > [...]
>>> > $ make DEBUG='-O0 -g3'
>>> > [...]
>>> > $ valgrin
with grep:
>> >
>> >$ make clean obj
>> >[...]
>> >$ make DEBUG='-O0 -g3'
>> >[...]
>> >$ valgrind obj/grep foo Makefile
>> >[...]
>> >==31128== Use of uninitialised value of size 8
>> &
On 2023/08/04 05:33:19 +0900, Masato Asou wrote:
> 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 n
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.
>>
>> [...]
>>
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 o
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
On Thu, Jul 13, 2023 at 10:05:53AM +0900, Masato Asou wrote:
> From: Masato Asou
> Date: Mon, 10 Jul 2023 08:05:16 +0900 (JST)
>
> > hi ports
> >
> > I made Valgrind 3.21.0 into a ports.
> >
> > In Valgrind 3.10.1 ports, some diffs were placed in
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 s
>> 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 f
>
> 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_
>
> 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_
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 miss
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
Since guenther removed pad arguments from various syscalls and renamed
the existing ones to contain a _pad_, the already rather outdated
vki-scnums-openbsd.h diverged a step too far from reality.
mmap() is now syscall 41, which valgrind thinks is getlogin(), so you
get output such as
==66088
on 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 fol
On Thu, Mar 25, 2021 at 09:50:17AM +0900, Masato Asou wrote:
> 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:/u
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
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 M
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,
> > >
> >
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 bef
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:
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
On Thu, Sep 24, 2020 at 05:30:51PM +0900, Masato Asou wrote:
> 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/com
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
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
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
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
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
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.
&g
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[])
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== M
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
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
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
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
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
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/pa
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
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 pr
l(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 hand
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 proble
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
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: unhan
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==
> -
YASUOKA Masahiko wrote:
> On Wed, 02 Oct 2019 08:35:26 -0600
> "Theo de Raadt" wrote:
> > YASUOKA Masahiko wrote:
> >> On Wed, 02 Oct 2019 07:24:46 -0600
> >> "Theo de Raadt" wrote:
> >> >> As far as my test (the log attached
On Wed, 02 Oct 2019 08:35:26 -0600
"Theo de Raadt" wrote:
> YASUOKA Masahiko wrote:
>> On Wed, 02 Oct 2019 07:24:46 -0600
>> "Theo de Raadt" wrote:
>> >> As far as my test (the log attached), valgrind seems to work with
>> >> &q
YASUOKA Masahiko wrote:
> On Wed, 02 Oct 2019 07:24:46 -0600
> "Theo de Raadt" wrote:
> >> As far as my test (the log attached), valgrind seems to work with
> >> "pledge" but not work with "unveil".
> >>
> >> Is there any f
On Wed, 02 Oct 2019 07:24:46 -0600
"Theo de Raadt" wrote:
>> As far as my test (the log attached), valgrind seems to work with
>> "pledge" but not work with "unveil".
>>
>> Is there any fundamental problem of valgrind to work with "ple
> As far as my test (the log attached), valgrind seems to work with
> "pledge" but not work with "unveil".
>
> Is there any fundamental problem of valgrind to work with "pledge"?
If unveil causes problems, then that means it is trying to access files.
unv
Hi,
On Tue, 1 Oct 2019 16:15:51 +0100
Stuart Henderson wrote:
> On 2019/10/01 11:13, Kurt Mosiejczuk wrote:
>> Unfortunately on my test amd64 box, valgrind still just abort traps on
>> launch.
>>
>> eisenhower$ valgrind
>> Abort trap
>> eisenhower$ valgr
On Tue, 1 Oct 2019 11:32:36 -0400
Kurt Mosiejczuk wrote:
> On Tue, Oct 01, 2019 at 04:15:51PM +0100, Stuart Henderson wrote:
>> On 2019/10/01 11:13, Kurt Mosiejczuk wrote:
>> > Unfortunately on my test amd64 box, valgrind still just abort traps on
>> > launch.
&
t; > > - Abort trap was occurred when lounched valgrind.
> >
> > > > $ cd /usr/ports/devel/valgrind
> > > > $ make && doas make install
> > > > $ valgrind /bin/ls
> > > > Abort trap
> > > > $
On 2019/10/01 11:13, Kurt Mosiejczuk wrote:
> On Tue, Oct 01, 2019 at 12:42:18PM +0200, Rafael Sadowski wrote:
> > On Tue Oct 01, 2019 at 03:54:32PM +0900, Masato Asou wrote:
>
> > > Additional information:
>
> > > - Abort trap was occurred when lounched valgr
On Tue Oct 01, 2019 at 03:54:32PM +0900, Masato Asou wrote:
> 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.
>
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 al
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
[ moved to ports@ ]
On 2017-05-25, Peter Ezetta wrote:
> Hello Misc,
>
> I have been trying to get Valgrind to run on OpenBSD 6.1-release, with
> all errata applied via syspatch(8), and I am having no luck. When
> executing Valgrind against any binary (or no binary at all), it
Oddly enough the aforementioned port's makefile doesn't have USE_WXNEEDED = yes
. After enabling this, and trying to build, configure fails with a ./conftest
triggering WX. mount -uo wxallowed /usr/obj allows it to build. However, in
accord with the bug #40 for valgrind-open
gt; > wrote:
> > > > Hi,
> > > >
> > > > Let me know if this should be on ports rather than here.
> > > >
> > > > I'm following OpenBSD current on amd64, updating the system a couple of
> > > > times a week, and I'm using valgrind fr
an here.
> > >
> > > I'm following OpenBSD current on amd64, updating the system a couple of
> > > times a week, and I'm using valgrind from ports to check a C program for
> > > memory leaks. However, since recently (sorry, can't specify closer
couple of
> > times a week, and I'm using valgrind from ports to check a C program for
> > memory leaks. However, since recently (sorry, can't specify closer,
> > within the last couple of months) I get a W^X violation when I try it.
>
> devel/valgrind is missing
On Thu, Oct 6, 2016 at 12:50 PM, Andreas Kusalananda Kähäri
wrote:
> Hi,
>
> Let me know if this should be on ports rather than here.
>
> I'm following OpenBSD current on amd64, updating the system a couple of
> times a week, and I'm using valgrind from ports to ch
/usr/bin)
> is not on
>> a wallowed filesystem.
>
> Right. Here:
>
> /usr/local/test$valgrind ex4
> valgrind: mmap(0x108000, 4198400) failed in UME with error 12 (Cannot
> allocate
> memory).
> /usr/local/test$dmesg | tail
> vscsi0 at root
> scsibus4 at
Have you tried it with an executable on /usr/local? cal (in /usr/bin) is not on
a wallowed filesystem.
On 9 July 2016 16:29:23 BST, Thomas Frohwein wrote:
>
>
>
>Independent of executable or doas/su, valgrind fails with the following
>error message for me on -current:
>$valg
Independent of executable or doas/su, valgrind fails with the following error
message for me on -current:
$valgrind cal
valgrind: mmap(0x108000, 4210688) failed in UME with error 12 (Cannot allocate
memory).
dmesg shows mmap W^X violation.
I'm not sure how to best find a solution to
Independent of executable or doas/su, valgrind fails with the following error
message for me on -current:$valgrind calvalgrind: mmap(0x108000, 4210688)
failed in UME with error 12 (Cannot allocate memory).dmesg shows mmap W^X
violation.I'm not sure how to best find a solution to this. Val
j...@wxcvbn.org (Jérémie Courrèges-Anglas) writes:
[...]
>> The solution here is to patch the port to link by invoking cc.
>>
>> 2. Ports that attempt to link code compiled without -fPIC into a
>>shared library:
>>
>> devel/valgrind
>
> This one lo
Mark Kettenis writes:
>> From: j...@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=)
>> Date: Thu, 21 May 2015 13:20:39 +0200
>>
>> > x11/pinot
>>
>> Fixed recently, but depends on graphics/exiv2 which is broken too. Are you
>> already looking at it?
>
> That should be fixed
> From: j...@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=)
> Date: Thu, 21 May 2015 13:20:39 +0200
>
> > x11/pinot
>
> Fixed recently, but depends on graphics/exiv2 which is broken too. Are you
> already looking at it?
That should be fixed by my last gcc and/or binutils com
> ld: foobar.o: relocation R_X86_64_PC32 against `__guard_local' can
> not be used when making a shared object; recompile with -fPIC
>
> The solution here is to patch the port to link by invoking cc.
>
> 2. Ports that attempt to link code compiled without -fPIC into a
&g
> Here are the failures from the latest amd64 package bulk build:
> >>
> >> devel/valgrind missing -fPIC
> >> games/freeciv picks up execinfo.h
> >> games/monadius SIGBUS
> >> mail/courier-imap "Cannot obtain infor
j...@wxcvbn.org (Jérémie Courrèges-Anglas) writes:
> Christian Weisgerber writes:
>
>> Here are the failures from the latest amd64 package bulk build:
>>
>> devel/valgrind missing -fPIC
>> games/freeciv picks up execinfo.h
>> games/monadius
Christian Weisgerber writes:
> Here are the failures from the latest amd64 package bulk build:
>
> devel/valgrind missing -fPIC
> games/freeciv picks up execinfo.h
> games/monadius SIGBUS
> mail/courier-imap "Cannot obtain inform
On Thu, Dec 11, 2014 at 5:22 PM, Masao Uebayashi wrote:
> Reflected your comments + others from zhuk@. Especially, in DESCR, mention
> "valgrind-openbsd" page to report problems.
>
> Any explicit OK?
Looks good.
Ok with me, and thanks for your work on valgrind!
ci
Reflected your comments + others from zhuk@. Especially, in DESCR, mention
"valgrind-openbsd" page to report problems.
Any explicit OK?
diff -Nru valgrind.orig/Makefile valgrind/Makefile
--- valgrind.orig/Makefile Thu Dec 4 22:59:34 2014
+++ valgrind/Makefile Fri Dec 12 01:
On 2014/12/11 16:24, Masao Uebayashi wrote:
> Here is the first attempt to port Valgrind to OpenBSD/amd64. Heavily based
> on that of FreeBSD.
>
> https://wiki.freebsd.org/Valgrind
> https://bitbucket.org/stass/valgrind-freebsd
I have a few minor tw
Here is the first attempt to port Valgrind to OpenBSD/amd64. Heavily based
on that of FreeBSD.
https://wiki.freebsd.org/Valgrind
https://bitbucket.org/stass/valgrind-freebsd
Minimal functionality, considered to be alpha release.
valgrind.tar.gz
Description: application/tar-gz
92 matches
Mail list logo
