On Thu, Apr 03, 2025 at 11:48:26AM +, Nathanial Sloss wrote:
> Module Name: src
> Committed By: nat
> Date: Thu Apr 3 11:48:26 UTC 2025
>
> Modified Files:
> src/external/gpl3/binutils/dist/gas/config: tc-m68k.c
>
> Log Message:
> Compiler support for buggy early revision 68LC
On 2025-02-24 10:28 pm, matthew green wrote:
"Christos Zoulas" writes:
Module Name:src
Committed By: christos
Date: Sun Feb 23 15:33:49 UTC 2025
Modified Files:
src/external/gpl3/gcc/dist/gcc/config/i386: avx2intrin.h
Log Message:
Pr/59093: Onno van der Linden: Elide ca
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Sun Feb 23 15:33:49 UTC 2025
>
> Modified Files:
> src/external/gpl3/gcc/dist/gcc/config/i386: avx2intrin.h
>
> Log Message:
> Pr/59093: Onno van der Linden: Elide cast-qual gcc warning
for dist code i rea
On Mon, Sep 11, 2023 at 12:27:25PM +1000, matthew green wrote:
> "Rin Okuyama" writes:
> > Module Name:src
> > Committed By: rin
> > Date: Mon Sep 11 01:54:18 UTC 2023
> >
> > Modified Files:
> > src/external/gpl3/binutils/dist/ld/emultempl: aarch64elf.em armelf.em
>
On 2023/09/11 11:27, matthew green wrote:
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Mon Sep 11 01:54:18 UTC 2023
Modified Files:
src/external/gpl3/binutils/dist/ld/emultempl: aarch64elf.em armelf.em
elf.em
Log Message:
ld: Enable --copy-d
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Mon Sep 11 01:54:18 UTC 2023
>
> Modified Files:
> src/external/gpl3/binutils/dist/ld/emultempl: aarch64elf.em armelf.em
> elf.em
>
> Log Message:
> ld: Enable --copy-dt-needed-entries by default again
th
On Tue, Sep 5, 2023 at 4:46 AM matthew green wrote:
>
> > I did similar verification for gdb/dist/bfd also. I'd like to
> > sync {binutils,gdb}/dist/bfd, but there are huge diffs between
> > them. Most of them seem like binutils or gdb specific fixes,
> > but I may overlook something...
> >
> > It
> I did similar verification for gdb/dist/bfd also. I'd like to
> sync {binutils,gdb}/dist/bfd, but there are huge diffs between
> them. Most of them seem like binutils or gdb specific fixes,
> but I may overlook something...
>
> It must be nice if we could unify two libbfd's. The upstream
> uses t
On 2023/08/28 19:55, Valery Ushakov wrote:
On Mon, Aug 28, 2023 at 00:02:50 +, Rin Okuyama wrote:
Log Message:
binutils/bfd: Adjust blank line to reduce diff from upstream
Thanks a lot for these cleanups!
Do we need to apply similar cleanups to the bfd version in gdb?
(external/gpl3/gdb/
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Sun Sep 3 18:45:26 UTC 2023
>
> Modified Files:
> src/external/gpl3/gcc.old/dist/gcc: ubsan.c
>
> Log Message:
> remap generated ubsan filename string labels. fixes reproducible builds.
> reported by wiz@
On Mon, Aug 28, 2023 at 00:02:50 +, Rin Okuyama wrote:
> Log Message:
> binutils/bfd: Adjust blank line to reduce diff from upstream
Thanks a lot for these cleanups!
Do we need to apply similar cleanups to the bfd version in gdb?
(external/gpl3/gdb/dist/bfd)
-uwe
Ah, it must be better. Thank you for useful comment as always :)
I've confirmed the same files are generated. I will commit soon, but
commit mail seems to be delayed for some reasons...
Thanks,
rin
On Sun, Aug 20, 2023 at 11:17 AM Valery Ushakov wrote:
>
> On Sun, Aug 20, 2023 at 02:02:40 +
On Sun, Aug 20, 2023 at 02:02:40 +, Rin Okuyama wrote:
> Modified Files:
> src/external/gpl3/gdb/dist/gnulib: configure
> src/external/gpl3/gdb/dist/gnulib/import/m4: rename.m4
>
> Log Message:
> gdb/gnulib: ``guess yes'' to rename(2) checks for NetBSD
Can't we just set gl_cv_fun
> For vax, something still wrong.
This was due to my test environment built by GCC 12. For system built by GCC 10,
GDB 13 works just fine (except for C++ exception handling), as far as I can see.
Thanks,
rin
On Thu, Aug 17, 2023 at 4:45 PM Rin Okuyama wrote:
>
> Module Name:src
> Committed
This was not correct. Core file support for NetBSD/riscv was present for
our local version of GDB 11, and lost during merge.
Thanks,
rin
On Thu, Aug 17, 2023 at 4:37 PM Rin Okuyama wrote:
>
> Module Name:src
> Committed By: rin
> Date: Thu Aug 17 07:37:36 UTC 2023
>
> Modified Fi
> binutils/bfd: Correct auxv offset for NetBSD, from gdb/bfd
binutils.old/bfd for this commit...
rin
On Thu, Aug 17, 2023 at 3:49 PM Rin Okuyama wrote:
>
> Module Name:src
> Committed By: rin
> Date: Thu Aug 17 06:49:01 UTC 2023
>
> Modified Files:
> src/external/gpl3/bi
> gcc/ppc: Register NetBSD OSABI for rs6000, lost during merge
oops, apparently "gdb/ppc", not "gcc".
Thanks,
rin
On Thu, Aug 17, 2023 at 2:53 PM Rin Okuyama wrote:
>
> Module Name:src
> Committed By: rin
> Date: Thu Aug 17 05:53:45 UTC 2023
>
> Modified Files:
> src/ext
I experimented with this, and my analysis of the gnulib emacs regexp
wasn't quite correct.
When I reverted this autoconf change, and fixed m4 as below,
regen works. I'm testing a full build of NetBSD now.
On 23-05-25 06:36, Luke Mewburn wrote:
| Hi Christos,
|
| Whilst this initially fixe
Hi Christos,
Whilst this initially fixed my tools/compat regen problem,
I'm not sure it's correct long term.
I think we need to revert this, and fix usr.bin/m4 -g (GNU)
emulation for m4 regexp() and patsubst() ?
A quick comparison of usr.bin/m4/gnum4.c twiddle() versus
https://www.gnu.org/sof
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Tue Feb 7 20:39:03 UTC 2023
>
> Modified Files:
> src/external/gpl3/binutils/dist/bfd: config.bfd elfn32-mips.c
note that the config.bfd changes here now mean there are two
copies of all 4 mips*netbsd* he
"Jared D. McNeill" writes:
> Module Name: src
> Committed By: jmcneill
> Date: Sat Sep 18 10:45:11 UTC 2021
>
> Modified Files:
> src/external/gpl3/gcc/dist/gcc/config: host-darwin.c
> src/external/gpl3/gcc/dist/gcc/config/aarch64: aarch64.h
>
> Log Message:
> Fix build on macO
> On Jul 15, 2021, at 12:06 AM, matthew green wrote:
>
> "Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Wed Jul 14 13:24:59 UTC 2021
>>
>> Modified Files:
>> src/external/gpl3/gcc/dist/gcc/ginclude: stddef.h
>>
>> Log Message:
>> cl
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Wed Jul 14 13:24:59 UTC 2021
>
> Modified Files:
> src/external/gpl3/gcc/dist/gcc/ginclude: stddef.h
>
> Log Message:
> clang does not support __float128 in our configuration and i386
shouldn't you replace
On 2021/04/22 10:09, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Thu Apr 22 01:09:48 UTC 2021
Modified Files:
src/external/gpl3/binutils/dist/bfd: elf32-ppc.c elf64-ppc.c
Log Message:
Fix regression where ld(1) is trapped into infinite loop when
linking bi
The condition is reversed. I will fix.
christos
> On Apr 26, 2021, at 10:31 PM, Rin Okuyama wrote:
>
> Hi,
>
> On 2021/04/26 7:25, Christos Zoulas wrote:
>> --- src/external/gpl3/gcc/usr.bin/cc1plus/Makefile:1.15 Sun Apr 11
>> 20:05:56 2021
>> +++ src/external/gpl3/gcc/usr.bin/cc1plus/Ma
Hi,
On 2021/04/26 7:25, Christos Zoulas wrote:
--- src/external/gpl3/gcc/usr.bin/cc1plus/Makefile:1.15 Sun Apr 11 20:05:56 2021
+++ src/external/gpl3/gcc/usr.bin/cc1plus/Makefile Sun Apr 25 18:25:55 2021
(snip)
-.if ${MACHINE_ARCH} == "mipseb" || ${MACHINE_ARCH} == "mipsel"
+.if ${MACHINE
On 10.12.2020 08:14, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Thu Dec 10 07:14:58 UTC 2020
>
> Modified Files:
> src/external/gpl3/gdb/dist/gdb: nbsd-nat.c
>
> Log Message:
> Fix arm, for which PT_STEP is defined but unimplemented.
>
> XXX
> Stop exposing
On Wed, Oct 21, 2020 at 08:58:36AM +0900, Rin Okuyama wrote:
> I'm also one who feels hesitate to import Linux'ism into our basic
> components. However, for this problem in particular, I still think
> it is not a good choice to keep NetBSD support in driver-aarch64.c:
>
> (a) Our sysctl(3)-based i
Hi,
(tech-toolchain@ added to cc)
On 2020/10/16 1:49, Kamil Rytarowski wrote:
On 15.10.2020 17:14, Rin Okuyama wrote:
On 2020/10/15 16:12, matthew green wrote:
Martin Husemann writes:
On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
you could try reverting most of our changes t
Date:Fri, 16 Oct 2020 04:07:31 +
From:"Thomas Mueller"
Message-ID: <20201016052422.e063084...@mail.netbsd.org>
| Should I add ,linux to the end of the procfs line?
You can, but it isn't needed these days -- I used to mount procfs twice,
once without the linux o
Excerpt from Rin Okuyama:
> Nowadays, -o linux is turned on by default (unless nolinux is
> specified explicitly). Still, native apps probably should not
> depend on it.
> This needs MI changes to procfs, not MD to aarch64. Should we
> enable /proc/cpuinfo unconditionally?
My NetBSD sys
On 15.10.2020 17:14, Rin Okuyama wrote:
> On 2020/10/15 16:12, matthew green wrote:
>> Martin Husemann writes:
>>> On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
you could try reverting most of our changes to this file and
making sure you run with /proc mounted -o linux.
On 2020/10/15 16:12, matthew green wrote:
Martin Husemann writes:
On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
you could try reverting most of our changes to this file and
making sure you run with /proc mounted -o linux. ryo@ recently
added additional /proc/cpuinfo support th
Martin Husemann writes:
> On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
> > you could try reverting most of our changes to this file and
> > making sure you run with /proc mounted -o linux. ryo@ recently
> > added additional /proc/cpuinfo support that should make this
> > just wor
On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
> you could try reverting most of our changes to this file and
> making sure you run with /proc mounted -o linux. ryo@ recently
> added additional /proc/cpuinfo support that should make this
> just work with the upstream version, but i
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Tue Oct 13 07:12:00 UTC 2020
>
> Modified Files:
> src/external/gpl3/gcc/dist/gcc/config/aarch64: driver-aarch64.c
>
> Log Message:
> Reduce diff with upstream a bit.
> No functional changes.
you could try revert
Thanks for fixing it!
christos
signature.asc
Description: Message signed with OpenPGP
On 13.10.2020 11:14, Leonardo Taccari wrote:
> Hello Kamil,
>
> Kamil Rytarowski writes:
>> Module Name: src
>> Committed By:kamil
>> Date:Tue Oct 6 23:14:47 UTC 2020
>>
>> Modified Files:
>> src/external/gpl3/gdb/dist/gdb: inf-ptrace.c nbsd-nat.c
>>
>> Log Message:
>
Hello Kamil,
Kamil Rytarowski writes:
> Module Name: src
> Committed By: kamil
> Date: Tue Oct 6 23:14:47 UTC 2020
>
> Modified Files:
> src/external/gpl3/gdb/dist/gdb: inf-ptrace.c nbsd-nat.c
>
> Log Message:
> Undo local patches
>
> They are no longer needed (and are wrong).
> [.
On 12.09.2020 23:36, Joerg Sonnenberger wrote:
> On Sat, Sep 12, 2020 at 10:24:16PM +0200, Kamil Rytarowski wrote:
>> On 12.09.2020 22:06, Joerg Sonnenberger wrote:
>>> On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote:
On 11.09.2020 23:38, Joerg Sonnenberger wrote:
> On Fri
On Sat, Sep 12, 2020 at 10:24:16PM +0200, Kamil Rytarowski wrote:
> On 12.09.2020 22:06, Joerg Sonnenberger wrote:
> > On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote:
> >> On 11.09.2020 23:38, Joerg Sonnenberger wrote:
> >>> On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarows
On 12.09.2020 22:06, Joerg Sonnenberger wrote:
> On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote:
>> On 11.09.2020 23:38, Joerg Sonnenberger wrote:
>>> On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote:
The current code is confusing, as it attempts to use unimpl
On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote:
> On 11.09.2020 23:38, Joerg Sonnenberger wrote:
> > On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote:
> >> The current code is confusing, as it attempts to use unimplemented
> >> _PTHREAD_GETTCB_EXT() and in one plac
On 11.09.2020 23:38, Joerg Sonnenberger wrote:
> On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote:
>> The current code is confusing, as it attempts to use unimplemented
>> _PTHREAD_GETTCB_EXT() and in one place uses _lwp_getprivate_fast() in
>> other _lwp_getprivate(). This caused m
On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote:
> The current code is confusing, as it attempts to use unimplemented
> _PTHREAD_GETTCB_EXT() and in one place uses _lwp_getprivate_fast() in
> other _lwp_getprivate(). This caused my confusion... as I assumed that
> _lwp_getprivate_f
On 11.09.2020 07:13, Rin Okuyama wrote:
> Hi again,
>
> On 2020/09/10 21:53, Kamil Rytarowski wrote:
>> Module Name: src
>> Committed By: kamil
>> Date: Thu Sep 10 12:53:06 UTC 2020
>>
>> Modified Files:
>> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common:
>> sanit
Hi again,
On 2020/09/10 21:53, Kamil Rytarowski wrote:
Module Name:src
Committed By: kamil
Date: Thu Sep 10 12:53:06 UTC 2020
Modified Files:
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common:
sanitizer_linux_libcdep.cc
src/external/gpl3/gcc/li
> Modified Files:
> src/external/gpl3/binutils/dist/bfd: Makefile.am Makefile.in
>
> Log Message:
> Fix `build.sh tools -j1` compilation, where bfd.h wasn't generated early
> enough.
FWIW, this looks right to me and not a hack. thanks.
.mrg.
On 05.09.2020 15:35, matthew green wrote:
> Module Name: src
> Committed By: mrg
> Date: Sat Sep 5 13:35:55 UTC 2020
>
> Modified Files:
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common:
> sanitizer_linux.cc sanitizer_linux.h sanitizer_linux_libcdep.cc
>
Sorry for the late reply.
On 2020/08/11 1:16, Valery Ushakov wrote:
This sounds eerily similar to port-macppc/54827 - there's quite a bit
of confusion early on on my part there, but scroll to the last couple
of mails. http://gnats.netbsd.org/54827
It looks like some logic changed in MI gcc8 th
> May be we should also check other ports for similar gotcha proactively?
good idea. no other gcc/config/*/*netbsd* files define the
nasty STACK_BOUNDARY macro so hopefully we're good now.
thanks!
.mrg.
On Mon, Aug 10, 2020 at 06:24:39 +, Rin Okuyama wrote:
> Modified Files:
> src/external/gpl3/gcc/dist/gcc/config/m68k: netbsd-elf.h
>
> Log Message:
> PR port-m68k/6
>
> Reset STACK_BOUNDARY to default, 16, to fix strange freeze for amiga,
> when kernel is compiled by GCC8.
This s
> Modified Files:
> src/external/gpl3/gcc/usr.bin/host-libcpp: Makefile
>
> Log Message:
> PR bin/55411 (Akihiko HAYASHI)
>
> Remove stray ``&&'' introduced in the previous revision, so that
> host tools are correctly passed to configure script.
>
> No similar problem for gcc.old. No relea
On 2020/06/02 17:03, matthew green wrote:
Module Name:src
Committed By: mrg
Date: Tue Jun 2 08:03:59 UTC 2020
Modified Files:
src/external/gpl3/gcc: gcc2netbsd
Log Message:
don't elide fortran components. we'd like to revive g77-as-gfortran.
To generate a diff of thi
Unfortunately this breaks building on a 9.0 arm64 host because it is
picking up /usr/include/aarch64/armreg.h and the one in 9.0 is missing a
bunch of stuff. It works when using armreg.h from the source tree instead,
eg:
-#include
+#include "/path/to/src/sys/arch/aarch64/include/armreg.h"
In article <20200429110459.0d9bcf...@cvs.netbsd.org>,
Rin Okuyama wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: rin
>Date: Wed Apr 29 11:04:58 UTC 2020
>
>Modified Files:
> src/external/gpl3/gdb/lib/libgdb: Makefile
>
>Log Message:
>PR toolchain/54820
>PR toolchain/54877
On 28.03.2020 05:39, matthew green wrote:
>> Date:Sat, 28 Mar 2020 11:46:29 +1100
>> From:matthew green
>> Message-ID: <15233.1585356...@splode.eterna.com.au>
>>
>> | can we just leave this as-is and let netbsd GCC people care?
>>
>> Only if the GCC people do care, a
On Sat, Mar 28, 2020 at 03:39:34PM +1100, matthew green wrote:
> we want both changes (libiberty, and my stdio.h/P_tmpdir
> change.) we want to support old netbsd, non-netbsd, ..
> whatever build hosts.
Can we have them in 8.2 please?
Martin
> Date:Sat, 28 Mar 2020 11:46:29 +1100
> From:matthew green
> Message-ID: <15233.1585356...@splode.eterna.com.au>
>
> | can we just leave this as-is and let netbsd GCC people care?
>
> Only if the GCC people do care, and understand the issue, and
> implement what w
Date:Sat, 28 Mar 2020 11:46:29 +1100
From:matthew green
Message-ID: <15233.1585356...@splode.eterna.com.au>
| can we just leave this as-is and let netbsd GCC people care?
Only if the GCC people do care, and understand the issue, and
implement what we want
Base
i don't like this "don't care about netbsd-8" feeling i'm hearing
when netbsd-9 is so freshly released. we only *just* dropped
caring about netbsd-7.
please care about netbsd-8 for now.
.mrg.
can we just leave this as-is and let netbsd GCC people care?
On Fri, Mar 27, 2020 at 02:11:36PM -0400, Greg Troxel wrote:
> I don't see why we don't care about 8. Given our release policy, that
> is supported until 10 is released.
It didn't have the local patch that Kamil wants to remove, so no change
there - but if we can fix it there too that would be a
Great to hear of progress.
I don't see why we don't care about 8. Given our release policy, that
is supported until 10 is released.
On 27.03.2020 18:42, Martin Husemann wrote:
> On Fri, Mar 27, 2020 at 06:36:29PM +0100, Kamil Rytarowski wrote:
>> I tested the code without our local patch as mentioned in my commit,
>> even in the snapshot 1 commit before jak@'s change.
>>
>> In all the cases I get P_tmpdir defined and pointing t
On Fri, Mar 27, 2020 at 06:36:29PM +0100, Kamil Rytarowski wrote:
> I tested the code without our local patch as mentioned in my commit,
> even in the snapshot 1 commit before jak@'s change.
>
> In all the cases I get P_tmpdir defined and pointing to "/tmp/".
>
> I have not tested it on NetBSD-8
On 27.03.2020 18:24, Martin Husemann wrote:
> On Fri, Mar 27, 2020 at 06:14:24PM +0100, Kamil Rytarowski wrote:
>> On 27.03.2020 16:01, Martin Husemann wrote:
>>> Which compiler version did you test?
>>>
>>
>> I tested on NetBSD HEAD GCC style distribution as host.
>
> Not sure I understand. You ne
On Fri, Mar 27, 2020 at 06:14:24PM +0100, Kamil Rytarowski wrote:
> On 27.03.2020 16:01, Martin Husemann wrote:
> > Which compiler version did you test?
> >
>
> I tested on NetBSD HEAD GCC style distribution as host.
Not sure I understand. You need to test the in-tree build with the change
backed
On 27.03.2020 16:01, Martin Husemann wrote:
> Which compiler version did you test?
>
I tested on NetBSD HEAD GCC style distribution as host.
$ uname -rms
NetBSD 9.99.51 amd64
> I see this on netbsd-8:
>
>> echo $TMPDIR
> TMPDIR: Undefined variable.
>> ktrace -i $TOOLDIR/bin/x86_64--netbsd-gcc b
Which compiler version did you test?
I see this on netbsd-8:
> echo $TMPDIR
TMPDIR: Undefined variable.
> ktrace -i $TOOLDIR/bin/x86_64--netbsd-gcc base64.c
[..]
> kdump | fgrep tmp
[..]
19418 1 collect2 NAMI "/var/tmp//ccs9D5nv.le"
19418 1 collect2 NAMI "/var/tmp//ccs9D5nv.le"
89
I've found out that this patch in not needed, at least on NetBSD and
likely Linux.
The algorithm to pick tmpdir is as follows:
- check for memoized tmpdir
- try env variables
- try P_tmpdir
- try /var/tmp, then /usr/tmp, then /tmp
- fallback to current dir ('.')
- save memoized tmpdir
P_tmp
Date:Thu, 26 Mar 2020 23:22:57 +
From:Andrew Doran
Message-ID: <20200326232257.gf27...@homeworld.netbsd.org>
| > Modern CPUs like Ryzen Threadripper 3990X can execute that extra amount
| > of instructions (around 600) in a single clock cycle.
|
| NetBSD-cu
On Thu, Mar 26, 2020 at 06:07:54PM +0100, Kamil Rytarowski wrote:
> On 26.03.2020 17:49, Robert Elz wrote:
> > Date:Thu, 26 Mar 2020 16:28:18 +0100
> > From:Kamil Rytarowski
> > Message-ID: <84460ebb-b4bf-f3ee-e51b-e27d0b6e2...@gmx.com>
> >
> >
> > | That is negligi
Date:Thu, 26 Mar 2020 18:07:54 +0100
From:Kamil Rytarowski
Message-ID: <723e979c-cb16-1a39-a51e-9d756f372...@gmx.com>
| But nonetheless, I'm trying to fix it un GCC without TMPDIR.
Not without, just without requiring. Something like tempnam(3)
works - if TMPDIR i
On 26.03.2020 17:49, Robert Elz wrote:
> Date:Thu, 26 Mar 2020 16:28:18 +0100
> From:Kamil Rytarowski
> Message-ID: <84460ebb-b4bf-f3ee-e51b-e27d0b6e2...@gmx.com>
>
>
> | That is negligible cost of getting TMPDIR propagated to most programs.
>
> Sure, it isn't much,
Date:Thu, 26 Mar 2020 16:28:18 +0100
From:Kamil Rytarowski
Message-ID: <84460ebb-b4bf-f3ee-e51b-e27d0b6e2...@gmx.com>
| That is negligible cost of getting TMPDIR propagated to most programs.
Sure, it isn't much, for one program, but when you're running tens of
tho
On 26.03.2020 17:03, Kamil Rytarowski wrote:
> On 26.03.2020 16:17, Greg Troxel wrote:
>> I don't think we can go from "upstream is unwilling to do X"
>> to "impose pain on NetBSD" by making "divergence bad" be the
>> highest-weighted concern. We have to say "what is the minimally
>> painful way
On 26.03.2020 16:17, Greg Troxel wrote:
> I don't think we can go from "upstream is unwilling to do X"
> to "impose pain on NetBSD" by making "divergence bad" be the
> highest-weighted concern. We have to say "what is the minimally
> painful way to cope".
I agree here that we want to get /tmp by
> Date: Thu, 26 Mar 2020 14:57:40 +0100
> From: Kamil Rytarowski
>
> Maybe we could specify TMPDIR somewhere in /etc and point to /tmp?
>
> The build of tools could be fixed independently.
It is wrong for gcc to abuse /var/tmp for files that aren't
meaningfully persistent, just like it would be
On 26.03.2020 16:02, Robert Elz wrote:
> EVery extra env var has a cost in every exec of absolutely everything.
As this is true.. but as I have benchmarked it.
For true(1) on amd64, we execute 0.05% more instructions for extra
TMPDIR environment variable.
$ ./singlestepper true
Total count: 1286
Generally speaking divergence with upstream is a problem and we lost
these changes anyway in pkgsrc and every standalone GNU toolchain copy.
Agreed that divergence is a problem, but so is having bugs. It's a
question of the right balance in each case.
Finding a creative way to make this at
On 26.03.2020 15:52, Greg Troxel wrote:
> What is the real problem here? I think it's great that NetBSD-specific
> fixes are being upstreamed, and that we are reducing gratuitous changes
> from upstream. But upstream's position that the default tmp should be
> /var/tmp is at odds with our and tra
Greg Troxel writes:
> It seem really obvious to me, and obvious that it is netbsd consensus,
> that a tool that needs tmp (without needing persistence) should default
> to /tmp. So I think it's unreasonable to follow upstream here, and
> unreasonable to ask everybody to either inherit some syste
Date:Thu, 26 Mar 2020 15:11:46 +0100
From:Kamil Rytarowski
Message-ID: <26eaf84f-616a-d48b-9a2f-7dd74cd69...@gmx.com>
| Right. Addressing tools build independently (honoring TMPDIR?)
This we should do.
| defining TMPDIR in /etc shell profile for common use insi
Kamil Rytarowski writes:
> On 26.03.2020 15:01, Martin Husemann wrote:
>> On Thu, Mar 26, 2020 at 02:57:40PM +0100, Kamil Rytarowski wrote:
>>> The build of tools could be fixed independently.
>> The problem is that we build the whole system with the tools gcc, and that
>> gcc misbehaves (or so I
On 26.03.2020 15:01, Martin Husemann wrote:
> On Thu, Mar 26, 2020 at 02:57:40PM +0100, Kamil Rytarowski wrote:
>> The build of tools could be fixed independently.
> The problem is that we build the whole system with the tools gcc, and that
> gcc misbehaves (or so I understood).
>
> So pointing TM
On Thu, Mar 26, 2020 at 02:57:40PM +0100, Kamil Rytarowski wrote:
> The build of tools could be fixed independently.
The problem is that we build the whole system with the tools gcc, and that
gcc misbehaves (or so I understood).
So pointing TMPDIR anywhere does not help.
Martin
On 26.03.2020 09:48, Martin Husemann wrote:
> On Thu, Mar 26, 2020 at 12:51:24AM +, Taylor R Campbell wrote:
>> We should keep the change. There is no semantic justification for
>> putting build-time temporary files in the directory for temporary
>> files that are meant to persist across reboo
On Thu, Mar 26, 2020 at 12:51:24AM +, Taylor R Campbell wrote:
> We should keep the change. There is no semantic justification for
> putting build-time temporary files in the directory for temporary
> files that are meant to persist across reboot. These temporary files
> _cannot_ be used if i
Date:Wed, 25 Mar 2020 20:59:59 -0400
From:Greg Troxel
Message-ID:
| I'll fourth this sentiment.
Me too (5th...)
The idea that /tmp is smaller than /var/tmp (or has less available space)
is based upon historic RAM sizes, my /tmp currently has about 10 times
as muc
Taylor R Campbell writes:
>> Do we insist on this patch? Can we remove it from local sources?
>
> We should keep the change. There is no semantic justification for
> putting build-time temporary files in the directory for temporary
> files that are meant to persist across reboot. These temporar
> Date: Thu, 26 Mar 2020 01:26:05 +0100
> From: Kamil Rytarowski
>
> Upstream (GCC) is strongly against this change (even under __NetBSD__
> ifdef) as /var/tmp is typically larger than /tmp:
>
> > I'd strongly recommend against this as-is.
> >
> > The whole reason we prefer /var/tmp is because i
We (to the extent I can assert that as an individual developer) insist
on keeping it.
Jonathan Kollasch
On Thu, Mar 26, 2020 at 01:26:05AM +0100, Kamil Rytarowski wrote:
> Upstream (GCC) is strongly against this change (even under __NetBSD__
> ifdef) as /var/tmp is typically larger than /
> On Mar 25, 2020, at 5:26 PM, Kamil Rytarowski wrote:
>
> Upstream (GCC) is strongly against this change (even under __NetBSD__
> ifdef) as /var/tmp is typically larger than /tmp:
>
>> I'd strongly recommend against this as-is.
>>
>> The whole reason we prefer /var/tmp is because it's often
Upstream (GCC) is strongly against this change (even under __NetBSD__
ifdef) as /var/tmp is typically larger than /tmp:
> I'd strongly recommend against this as-is.
>
> The whole reason we prefer /var/tmp is because it's often dramatically
larger
> than a ram-backed /tmp.
-- by Jeff Law.
Do we i
Yup, undo it.
christos
> On Mar 14, 2020, at 2:35 PM, Kamil Rytarowski wrote:
>
> Signed PGP part
> On 26.02.2016 17:28, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Fri Feb 26 16:28:14 UTC 2016
>>
>> Modified Files:
>> src/external/g
On 26.02.2016 17:28, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Fri Feb 26 16:28:14 UTC 2016
>
> Modified Files:
> src/external/gpl3/gdb/dist/bfd: merge.c
>
> Log Message:
> CID 420802: Avoid NULL deref.
>
>
> To generate a diff of this commit:
> c
1. It does now (my commit to configure.tgt)
2. ah, ok, thanks. Perhaps they should not.
christos
> On Nov 21, 2019, at 9:49 PM, Kamil Rytarowski wrote:
>
>
>
> On 22.11.2019 03:40, Christos Zoulas wrote:
>> And why copy the structs? Doesn't #include work?
>>
>
> http://mail-index.netbsd.or
On 22.11.2019 03:40, Christos Zoulas wrote:
> And why copy the structs? Doesn't #include work?
>
http://mail-index.netbsd.org/tech-toolchain/2019/06/22/msg003508.html
1. mknative does not include i386 files for x86_64 mode
_initialize_i386nbsd_tdep() and associated i386 GDB files are not
And why copy the structs? Doesn't #include work?
christos
> On Nov 21, 2019, at 9:37 PM, Christos Zoulas wrote:
>
> That's for kernel debugging?
>
> christos
>
>> On Nov 21, 2019, at 9:35 PM, Kamil Rytarowski wrote:
>>
>> On 22.11.2019 02:52, Christos Zoulas wrote:
>>> Module Name:
1 - 100 of 192 matches
Mail list logo
