Re: how do I preset ddb's LINES to zero

On Fri, 15 Dec 2023 at 22:59, matthew green wrote: > > Andrew Cagney writes: > > > > thanks, I'll add that (it won't help with my immediate problem of a > > > > panic during boot though) > > > > > > From DDB command prompt "set $lines = 0"

Re: how do I preset ddb's LINES to zero

> > thanks, I'll add that (it won't help with my immediate problem of a > > panic during boot though) > > From DDB command prompt "set $lines = 0" ... Um, the test framework's VM is stuck waiting for someone to hit the space bar :-) I guess I could modify my pexpect script to do just that, but I

Re: how do I preset ddb's LINES to zero

On Fri, 15 Dec 2023 at 11:22, J. Hannken-Illjes wrote: > > Is there a way to stop this without having to rebuild the kernel. > > sysctl -w ddb.lines=0 thanks, I'll add that (it won't help with my immediate problem of a panic during boot though)

how do I preset ddb's LINES to zero

Hi, I've the stock 10.0 boot.iso booting within a KVM based test framework. I'd like to set things up so that should there be a panic, it dumps registers et.al., without stopping half way waiting for someone to hit the space bar vis: r9 af80b451d080 r10 81d9a063 r11

Re: [PATCH] style(5): No struct typedefs

On Tue, 11 Jul 2023 at 06:17, Taylor R Campbell wrote: > > I propose the attached change to KNF style(5) to advise against > typedefs for structs or unions, or pointers to them. Perhaps be positive? Add a section encouraging the use of struct, union and enum forward declarations when the

sadb_x_policy_reserved -> sadb_x_policy_flags

I just noticed this rename when building libreswan against 10. Can I suggest adding: #define sadb_x_policy_flags sadb_x_policy_flags to signal this change to consumers? Or perhaps there is some other way to detect if this change is present? As an aside, FreeBSD hid their rename by defining:

IPsec gsoc project

I noticed this project on the GSOC list filed under userland: http://wiki.netbsd.org/projects/project/ikev2/ racoon(8) is the current IKEv1 implementation used in NetBSD. The racoon code is old and crufty and full of potential security issues. We would like to replace it. [Libreswan can be added

Re: valgrind

On Fri, 25 Mar 2022 at 10:03, Reinoud Zandijk wrote: > > I guess they can think so because nested functions are a gcc extension. > > Quite a useful one, I think, having been taught programming with Algol > > 68 which of course does have nested functions; but an extension > > nevertheless. > >

Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl

On Sat, 16 Oct 2021 at 09:12, John Marino (NetBSD) wrote: > > Alright, so I think we have established that it's impossible to > provide KERN_PROC_SIGTRAMP as it functions on FreeBSD and DragonFly. > The purpose of that sysctl is to get the address range of the single > signal trampoline. Backing

Re: ptrace(2) interface for TLSBASE

rrupts those structures, well ... :-) But I digress. > On 04.12.2019 16:56, Andrew Cagney wrote: > > Where is it in a core file? > > > > On Tue, 3 Dec 2019 at 11:18, Kamil Rytarowski wrote: > >> > >> TLSBASE is stored on a selection of ports in a

Re: ptrace(2) interface for TLSBASE

Where is it in a core file? On Tue, 3 Dec 2019 at 11:18, Kamil Rytarowski wrote: > > TLSBASE is stored on a selection of ports in a dedicated mcontext entry, > out of gpregs. > > In the amd64 case mcontext looks like this: > > typedef struct { > __gregset_t __gregs; >

Re: __{read,write}_once

On Wed, 6 Nov 2019 at 09:57, Jason Thorpe wrote: > > > > > On Nov 6, 2019, at 5:41 AM, Kamil Rytarowski wrote: > > > > On 06.11.2019 14:37, Jason Thorpe wrote: > >> > >> > >>> On Nov 6, 2019, at 4:45 AM, Kamil Rytarowski wrote: > >>> > >>> I propose __write_relaxed() / __read_relaxed(). > >> >

Re: re-enabling debugging of 32 bit processes with 64 bit debugger

On Mon, 1 Jul 2019 at 10:06, Kamil Rytarowski wrote: > > On 01.07.2019 16:01, Christos Zoulas wrote: > > In article , > > Michael van Elst wrote: > >> chris...@astron.com (Christos Zoulas) writes: > >> > >>> We can fill them completely with 0 as we pad with 0 the 32 bit > >>> part of the 64 bit

Re: re-enabling debugging of 32 bit processes with 64 bit debugger

On Sun, 30 Jun 2019 at 10:28, Jason Thorpe wrote: > > > > On Jun 30, 2019, at 6:46 AM, Andrew Cagney wrote: > > > > Things started to go down hill when the debugger developers decided > > that rooting around in the process to extract the memory map was "

Re: re-enabling debugging of 32 bit processes with 64 bit debugger

On Sat, 29 Jun 2019 at 16:04, Christos Zoulas wrote: > > In article > , > Andrew Cagney wrote: > > > >Having 32-bit and 64-bit debuggers isn't sufficient. Specifically, it > >can't handle an exec() call where the new executable has a different > >

Re: re-enabling debugging of 32 bit processes with 64 bit debugger

> > What do you think? SHould we make the code work like before? Or this is > > functionality that we don't want to have because it is "dumb"? (I think > > that Max here means that it adds complexity and it could be dangerous, > > but I am just guessing) > > I'm baffled that this is even

Re: RFC: New userspace fetch/store API

On Mon, 25 Feb 2019 at 11:35, Eduardo Horvath wrote: > > On Sat, 23 Feb 2019, Jason Thorpe wrote: > > > int ufetch_8(const uint8_t *uaddr, uint8_t *valp); > > int ufetch_16(const uint16_t *uaddr, uint16_t *valp); > > int ufetch_32(const uint32_t *uaddr, uint32_t *valp); > > #ifdef

Re: RFC: New userspace fetch/store API

On Sun, 24 Feb 2019 at 10:38, Jason Thorpe wrote: > > > > On Feb 24, 2019, at 7:05 AM, Andrew Cagney wrote: > > > > Can there be an inefficient default, implemented using something like > > copy{in,out}() (yes I note the point about alignment). I sometimes >

Re: RFC: New userspace fetch/store API

On Sat, 23 Feb 2019 at 18:26, Jason Thorpe wrote: > A project I’m working on has a need for a proper “int” size fetch / store on > all platforms, and it seems best to just tidy the whole mess up. So, I am > proposing a new replacement user fetch/store API. Can you be more specific on why

Re: awge0 and 100mb?

On 26 April 2018 at 11:26, Manuel Bouyer <bou...@antioche.eu.org> wrote: > On Thu, Apr 26, 2018 at 11:20:22AM -0400, Andrew Cagney wrote: >> > I tested on a olimex lime2 (A20 with a realtek Gbe PHY), it doens't make a >> > difference either. >> >> Unfortu

awge0 and 100mb?

Hi, Anyone had, er, fun trying to get awge0 to connect at 100mb? I foolishly changed the hub that my working odroid c1 was connected to and after that packets refused to flow (other end didn't see them). Switching it back restored connectivity. After some thrashing about I noticed that while

Re: gcc: optimizations, and stack traces

Two things come to mind: - was this the innermost (newest) frame? If it wasn't something earlier could be the problem - is the dwarf debug info being used, or is it relying on heuristics (annoyingly I can't spot an easy way to tell) and when this happens, 'info frame' may help diagnose things.

Re: gcc: optimizations, and stack traces

On 23 February 2018 at 03:41, Maxime Villard wrote: > Many of our ASM functions don't push frames, but that's a different issue. /me mumbles something about the assembler needing to be marked up with .cfi directives

Re: starting dhclient on odroid-c1 (arm)

>> > I fixed this in -current, but probably didn't ask for pullup yet (the >> > change breaking it only recently got pulled up in #456). >> >> >> Ah, I'll wait for more branch changes then try again. Thanks. > > It has been pulled up last night. Yes, working now. Thanks.

Re: starting dhclient on odroid-c1 (arm)

On 12 January 2018 at 09:32, Martin Husemann <mar...@duskware.de> wrote: > On Fri, Jan 12, 2018 at 09:27:47AM -0500, Andrew Cagney wrote: >> # uname -a >> NetBSD 8.0_BETA NetBSD 8.0_BETA (ODROID-C1) #1: Wed Jan 10 00:55:46 >> EST 2018 evbearmv7hf-el/sys/arch/evba

starting dhclient on odroid-c1 (arm)

# uname -a NetBSD 8.0_BETA NetBSD 8.0_BETA (ODROID-C1) #1: Wed Jan 10 00:55:46 EST 2018 evbearmv7hf-el/sys/arch/evbarm/compile/ODROID-C1 evbarm # /etc/rc.d/dhclient onestart Starting dhclient. # panic: kernel diagnostic assertion "if_is_mpsafe(ifp)" failed: file

Re: ptrace(2) interface for hardware watchpoints (breakpoints)

On 15 December 2016 at 13:23, Kamil Rytarowski wrote: > BTW. I'm having some DWARF related questions, if I may reach you in a > private mail? > Better is http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org so you don't have me as a bottle neck. Andrew

Re: ptrace(2) interface for hardware watchpoints (breakpoints)

On 15 December 2016 at 13:22, Eduardo Horvath <e...@netbsd.org> wrote: > > On Thu, 15 Dec 2016, Andrew Cagney wrote: > > > Might a better strategy be to first get the registers exposed, and then, > if > > there's still time start to look at an abstract interface?

Re: ptrace(2) interface for hardware watchpoints (breakpoints)

On 13 December 2016 at 12:16, Kamil Rytarowski wrote: > >> 5. Do not allow to mix PT_STEP and hardware watchpoint, in case of > >> single-stepping the code, disable (it means: don't set) hardware > >> watchpoints for threads. Some platforms might implement single-step with > >>

Re: ptrace(2) interface for hardware watchpoints (breakpoints)

[see end] On 13 December 2016 at 12:16, Kamil Rytarowski wrote: > On 13.12.2016 04:12, Valery Ushakov wrote: > > On Tue, Dec 13, 2016 at 02:04:36 +0100, Kamil Rytarowski wrote: > > > >> The design is as follows: > >> > >> 1. Accessors through: > >> - PT_WRITE_WATCHPOINT - write

Re: nick-nhusb merge coming soon

On 28 April 2016 at 06:56, Paul Goyette wrote: > On Wed, 13 Apr 2016, Paul Goyette wrote: > >> Does this include xhci support for USB3 (ie, removal of the "experimental" >> tag)? > > > FWIW, I finally got around to checking the status of USB3 on my machine. > > Firstly, let me

Re: Patch: CPU RNG framework with stub x86 implementation

On 10 January 2016 at 21:08, Thor Lancelot Simon wrote: > As requested - here's just "cpu_rng" itself for review. I believe this > version addresses all comments received so far except that I _like_ the > construct "size_t cnt = ; type_t foo[x]" so I've retained > that.

Re: Guidelines for choosing MACHINE MACHINE_ARCH?

On 24 June 2015 at 23:38, David Holland dholland-t...@netbsd.org wrote: On Wed, Jun 24, 2015 at 04:01:24PM -0700, Matt Thomas wrote: I agree that evb* is confusing and increasingly meaningless and would like to see us transition away from it. I contend that moving to sys/arch/cpu

Re: lua kernel library?

On 18 June 2015 at 05:58, Valery Ushakov u...@stderr.spb.ru wrote: On Wed, Jun 17, 2015 at 09:55:31 -0400, Andrew Cagney wrote: pulling stuff like memory into Lua has proven relatively painless (which reminds me, how do I silently detect that db_read_bytes failed). Do you mean detecting

Re: lua kernel library?

On 17 June 2015 at 02:43, matthew green m...@eterna.com.au wrote: what sort of support from ddb do you need? ddb supports run-time addition of commands, so i imagine that with the right glue you could easily add a lua ddb command with a module. That's useful to know. Since I'm playing, I

Re: lua kernel library?

On 17 June 2015 at 00:48, Lourival Vieira Neto lourival.n...@gmail.com wrote: Is the kernel's version of Lua available as a library? You can use it as a regular kernel module. Take a look at this patch [1] which adds Lua to NPF, as an example. thanks, I'd looked briefly at the lua et.al.

lua kernel library?

Hi, Is the kernel's version of Lua available as a library? I suspect adding this: fileddb/db_lua.cddb makeoptions ddb CPPFLAGS+=-I$S/../external/mit/lua/dist/src makeoptions ddb CPPFLAGS+=-I$S/sys makeoptions ddb CPPFLAGS+=-Wno-error=cast-qual makeoptions ddb

Re: lua kernel library?

On 16 June 2015 at 13:52, Lourival Vieira Neto lourival.n...@gmail.com wrote: Hi Andrew, Is the kernel's version of Lua available as a library? You can use it as a regular kernel module. Take a look at this patch [1] which adds Lua to NPF, as an example. thanks, I'd looked briefly at the

Re: Removing ARCNET stuffs

On 8 June 2015 at 13:18, Anders Magnusson ra...@ludd.ltu.se wrote: David Holland skrev den 2015-06-08 19:06: On Mon, Jun 08, 2015 at 04:15:15PM +0200, Anders Magnusson wrote: printfing from the back of the front end is definitely totally wrong in other ways that need to be rectified

Re: Removing ARCNET stuffs

Oops, s/epilogue/prologue/ in below On 8 June 2015 at 15:15, David Holland dholland-t...@netbsd.org wrote: On Mon, Jun 08, 2015 at 07:18:24PM +0200, Anders Magnusson wrote: David Holland skrev den 2015-06-08 19:06: On Mon, Jun 08, 2015 at 04:15:15PM +0200, Anders Magnusson wrote:

Re: Removing ARCNET stuffs

I'm clearly out-of-date regarding SSA, its nice to be corrected. On 8 June 2015 at 09:06, Anders Magnusson ra...@ludd.ltu.se wrote: Andrew Cagney skrev den 2015-06-01 20:41: I do not understand why either of those choices need to be taken. Pcc has a reasonable intermediate representation

Re: retrocomputing NetBSD style

GAW Wrote: I really don't understand anyone who has the desire to try to run build.sh on a VAX-750 to build even just a kernel, let alone the whole distribution. I recall a time where NetBSD/vax was broken for a long time because everyone was cross-building; as soon as a native build

Re: Removing ARCNET stuffs

On 3 June 2015 at 01:56, David Holland dholland-t...@netbsd.org wrote: On Mon, Jun 01, 2015 at 02:41:22PM -0400, Andrew Cagney wrote: To my mind, and I'm assuming a pure SSA compiler design, having SSA forces issues like: [...] I'm missing something; SSA is just a style

Re: Removing ARCNET stuffs

On 1 June 2015 at 02:15, Anders Magnusson ra...@ludd.ltu.se wrote: Andrew Cagney skrev den 2015-06-01 03:24: systems and generates reasonable code. Unfortunately, and sorry PCC (stabs, really?), Feel free to add dwarf, the source is out there, and it wouldn't be especially difficult to do

Re: Removing ARCNET stuffs

On 1 June 2015 at 12:54, David Holland dholland-t...@netbsd.org wrote: On Mon, Jun 01, 2015 at 11:41:38AM -0400, Andrew Cagney wrote: systems and generates reasonable code. Unfortunately, and sorry PCC (stabs, really?), Feel free to add dwarf, the source is out

Re: Removing ARCNET stuffs

(oh and please delete C++ groff, just replace it with that AWK script) which awk script? :-) (quite seriously, I've been looking for a while for an alternative to groff for typesetting the miscellaneous articles in base. I was thinking of http://doc.cat-v.org/henry_spencer/awf/ which I

Re: Removing ARCNET stuffs

On 1 June 2015 at 13:50, David Holland dholland-t...@netbsd.org wrote: but ignoring that -- who (other than apparently the gcc development team) is focusing on burning ram? GNU, this is from the GNU coding standard; to me it explains some of the design choices I find in many GNU utilities: For

Re: Removing ARCNET stuffs

On 1 June 2015 at 15:13, Iain Hibbert plu...@ogmig.net wrote: On Mon, 1 Jun 2015, Andrew Cagney wrote: PCC, as a classic C compiler, only generates debug information at -O0. This this is because the stabs code is restricted to the un-optimized code generator path. this is not actually

Re: Removing ARCNET stuffs

Yes, I'm being hypocritical :-) On 31 May 2015 at 02:05, matthew green m...@eterna.com.au wrote: hi Andrew! :) Who is appalled to discover that pc532 support has been removed! get your GCC and binutils and GDB pals to put the support back in the toolchain and we'll have something to talk

Re: Removing ARCNET stuffs

On 30 May 2015 at 19:09, David Holland dholland-t...@netbsd.org wrote: The reason I floated the idea of forking is that an OS that's specifically intended to be a high-quality Unix for older hardware can make a different set of decisions (most notably, it can let C++ go hang) and this allows

Re: Removing ARCNET stuffs

There's a complex tradeoff here On 29 May 2015 at 12:09, J. Lewis Muir jlm...@imca-cat.org wrote: In Evolving Frameworks, [2] Don Roberts and Ralph Johnson suggest in the Tree Examples pattern that you should never write a software framework unless you have at least three applications that use

Re: .eh_frame

On 9 November 2014 17:12, Joerg Sonnenberger jo...@britannica.bec.de wrote: o .eh_frame in kernel is not used yet, and safely removed from /netbsd Please do not. o Is it correct that .eh_frame is not used by anything at all at the moment? gdb should in principle, haven't tried. libunwind

Re: .eh_frame

On 10 November 2014 18:21, Joerg Sonnenberger jo...@britannica.bec.de wrote: Consider x86_64 where you can't do reliable stack unwinding without also disabling -fomit-frame-pointer. The question is not about .debug_frame vs .eh_frame, you don't get the former at all without explicitly asking

Re: .eh_frame

On 10 November 2014 06:53, Masao Uebayashi uebay...@gmail.com wrote: So, does your kernel contain C++ code using exceptions, hand written eh-frame code, or an in kernel consumer? :-) According to joerg@, there is nothing (yet). BTW, looks like arm (sys/arch/arm/include/profile.h) may contain

Re: .eh_frame

You might find this useful: http://lists.cs.uiuc.edu/pipermail/lldb-dev/2014-October/005546.html Several notes: - while eh_frame is meant to be the minimum information needed to unwind function calls, the desire to unwind through C code and signals from C++ means that most systems ship with the