Re: Anyone recall the dreaded tstile issue?
> On Jul 19, 2022, at 6:45 PM, Mouse wrote: > > > [EXTERNAL EMAIL] > >>> [...kernel coredump...kernel stack traces...] >>> [...dig up a way to get userland stack traces...] > >> I did a pile of work on GDB, 10 or more years ago, to add that >> capability for the non-standard system coredumps we used in >> EqualLogic. It's not a simple change, if you want it to be fairly >> automatic. Part of it means looking into user mode memory, but >> another part is loading all the right symbol tables with the right >> relocations. > > I'd be satisfied with a no-symbols stack trace, the kind of thing you > could get from a (userland) coredump without the matching binary. If I > didn't already have a fair idea what the problem is, I'd be trying to > add a way to do that. Good point, though I've found that no-symbols is painful when shared libraries are involved because it makes it very hard to figure out what that number translates to. >> Unfortunately I'm not in a position to dig up that code, adapt it to >> the standard NetBSD kernel dumps, and contribute it. I could ask for >> approval to contribute my changes as-is for some interested person to >> adapt. If that's interesting, please let me know and I can pursue >> it. > > I probably am not in a position to do that work at all, and certainly > not to do it in a way that would be useful to NetBSD. > > I don't know whether anyone else is. But it does occur to me that > having the underlying code available would make it more likely that > someone would pick it up in the future. That makes sense. Ok, I'll bring up the question with management. paul
Re: Anyone recall the dreaded tstile issue?
> On Jul 19, 2022, at 9:57 AM, Mouse wrote: > > > [EXTERNAL EMAIL] > > I've been exchanging email off-list about this with a few people. One > of them remarked that a kernel coredump would help. > > Yesterday it wedged again. I got a kernel coredump...and, well, as I > put it in off-list mail: > >>> I now realize I don't know how to coax [process stack traces] out of >>> a kernel core. I don't recall hearing of any sort of postmortem >>> ddb. I have a the corresponding netbsd.gdb, and I found gdb's >>> target kvm, but I haven't manged to get a stack trace for any >>> process out of it. > > The response turned out to be exactly the cluesticking I needed to get > stack traces. I did a pile of work on GDB, 10 or more years ago, to add that capability for the non-standard system coredumps we used in EqualLogic. It's not a simple change, if you want it to be fairly automatic. Part of it means looking into user mode memory, but another part is loading all the right symbol tables with the right relocations. Unfortunately I'm not in a position to dig up that code, adapt it to the standard NetBSD kernel dumps, and contribute it. I could ask for approval to contribute my changes as-is for some interested person to adapt. If that's interesting, please let me know and I can pursue it. pul
Re: pcc [was Re: valgrind]
> On Mar 22, 2022, at 1:21 PM, Greg A. Woods wrote: > > At Mon, 21 Mar 2022 08:54:43 -0400 (EDT), Mouse > wrote: > Subject: pcc [was Re: valgrind] >> I've been making very-spare-time progress on building my own compiler on and off for some years now; perhaps I'll eventually get somewhere. [...] >>> Have you looked at pcc? http://pcc.ludd.ltu.se/ and in our source >>> tree in src/external/bsd/pcc . >> >> No, I haven't. I should - it may well end up being quicker to move an >> existing compiler in the directions I want to go than to write my own. > > ... > I also really like PCC. (I remember teething pains getting used to it > back when it first replaced Ritchie C on my university's PDP-11/60, but > once I actually used it for real code (i.e. assignments in those days), > and soon on the Vax too, I really liked it.) > > I'm really sad that I still cannot build NetBSD entirely with PCC as the > native and only default compiler. Out of curiosity: how does PCC code quality compare with that of GCC and (for targets that it supports) Clang? paul
Re: valgrind
> On Mar 22, 2022, at 5:11 PM, Rhialto wrote: > > On Tue 22 Mar 2022 at 20:59:05 +0000, Koning, Paul wrote: > ... >> If it does, that would mean you can't get a pointer to a nested >> function, which is no different from the C++ rule that you can't get a >> (plain function) pointer to a member function. > > True. But the trampoline function on the stack are only needed to create > a pointer to a nested function. I don't think there is any issue if you > never create such pointers. But that would make nested functions a lot > less useful. You couldn't use one with qsort(3) for instance (as the > comparison function), which is exactly the sort of scenario that would > be perfect for a nested function. Yes, though in that case the pointer is of a specific type, so you don't need what you pointed out as missing, the generic function pointer. > Possibly, a trampoline could be created on the heap, and then made > executable and un-writable. Maybe that's considered too complicated / > system dependent / expensive by gcc? Perhaps. But the bigger issue is that the heap isn't normally executable either, and all the same arguments for why the stack should not be executable apply to the heap also. paul
Re: valgrind
> On Mar 22, 2022, at 4:53 PM, Rhialto wrote: > > On Tue 22 Mar 2022 at 17:46:49 +0000, Koning, Paul wrote: >> I don't believe ALGOL implementations needed executable stacks to implement >> nested functions, for example. > > No, a common way to do it (as in the Dragon Book), if I recall > correctly, the address of the function combined with a stack frame > pointer. And nested functions keep a static link to the lexically > enclosing scope, or alternatively a "display". I'm not sure if A68 would > automatically move locals from surrounding scopes into the heap (like in > a closure); it could well be that there was run-time checking instead if > you tried to use a function pointer outside of the scope of any of the > locals it used. > > But these sorts of strategies require bigger function pointers, which > you basically can't do in C. Can't you? Does C require function pointers to have the same type, or compatible structure, as data pointers? If it does, that would mean you can't get a pointer to a nested function, which is no different from the C++ rule that you can't get a (plain function) pointer to a member function. paul
Re: nested functions [was Re: valgrind]
> On Mar 22, 2022, at 2:23 PM, Mouse wrote: > > > [EXTERNAL EMAIL] > >>> I found an interesting article about why they're bad... >>> https://urldefense.com/v3/__https://thephd.dev/lambdas-nested-functions-block-expressions-oh-my__;!!LpKI!1zB1gatUTEiM-j9CQ_6N-NWd4jS8UvW5iTSMRgW1tEyW_mK0mG2pU48LnUwJJBvA$ >>> [thephd[.]dev] >> That's a good argument for why GCC's implementation of nested functions is b$ > > What security blunder is that? Based on your next line, I'm going to > assume it's "implementing them via stack trampolines". (I would have > to go to a work machine to tell, because thephd.dev has apparently > drunk the "it's good to ram HTTPS down everyone's throat" koolaid. > Even the stack trampoline mechanism, I would say, is not a security > blunder per se; I see it as a security issue only in that it > exacerbates the effects of certain other security issues. Also don't > forget that early gcc arose in a very different environment from > today's.) Yes, I did mean executable stacks. True, the world was different once, though executable stacks are also problematic on some older architectures for entirely different reasons. For example, you can't necessarily use them on PDP-11s. >> I don't believe ALGOL implementations needed executable stacks to implement $ > > Neither would gcc...IF it can set the ABI. There really was very > little choice for gcc when it started. It had to be ABI-compatible > with existing procedure calling sequences. It also had to be > compatible with existing longjmps. That eliminates pretty close to > everything _but_ stack trampolines. True. Do general ABIs like the VAX one have this issue or is it specific to just some of the ABIs? > Other ways of doing nested functions is one of the things I want to > experiment with. I know the classic answer in ALGOL is "displays", which go all the way back to the first ALGOL compilers, but I don't have the details in my head. paul
Re: valgrind
> On Mar 22, 2022, at 1:17 PM, Rhialto wrote: > > On Sun 20 Mar 2022 at 23:17:57 -0400, Mouse wrote: >> clang is - or at least was last I checked - under the impression that >> nested functions are little-used and thus are not worth supporting. > > 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. > > I found an interesting article about why they're bad... > https://thephd.dev/lambdas-nested-functions-block-expressions-oh-my That's a good argument for why GCC's implementation of nested functions is bad. It doesn't mean other implementations that avoid the security blunder GCC made are bad. I don't believe ALGOL implementations needed executable stacks to implement nested functions, for example. paul
Re: valgrind
> On Mar 20, 2022, at 7:58 PM, Mouse wrote: > > > [EXTERNAL EMAIL] > >>> Perhaps I just need a better approach > >> I know you've previously expressed a lack of interest in such things >> when we've talked previously, but I've found the built-in sanitizers >> in modern GCC useful for approximating the functionality of valgrind >> on NetBSD. > > To some extent, perhaps. > > But it's less a lack of interest and more an unwillingness to ignore > the licensing issues. `Modern' GCC is licensed under the GPLv3. So? That doesn't affect the licensing of code compiled by gcc. paul
Re: about langage neutral
> On Mar 9, 2022, at 5:18 AM, jo...@nonadev.net wrote: > > Hello tech-kern, > > I'm discorvering the article about language-neutral-interfaces for system > calls. > > https://urldefense.com/v3/__http://wiki.netbsd.org/projects/project/language-neutral-interfaces/__;!!LpKI!yl7D58zoWsSSbdJtiN2wy-TFHG_ZBOOxRhDgtdG8Eu3oECNsxINMFjwJ6qB-m9C4$ > [wiki[.]netbsd[.]org] > > That is a very interesting topic. > > IMHO scheme language is well suited to answer the issue. > > Are you interested in more discussion around that topic? Isn't this what SWIG tries to do? One might argue about how well it does it. As for Scheme, I thought that's a programming language, and a rather exotic one at that. Or do you mean something else called "scheme"? paul
Re: wsvt25 backspace key should match terminfo definition
> On Nov 23, 2021, at 12:53 PM, Valery Ushakov wrote: > > > On Tue, Nov 23, 2021 at 09:22:43 -0500, Greg Troxel wrote: > >> >> I think (memory is getting fuzzy) the problem is that the old terminals >> had a delete key, in the upper right, that users use to remove the >> previous character, and a BS key, upper left, that was actually a >> carriage control character. > [... snip ...] >> I see the same kbs=^H on vt52. > > vt52 is different. I spent a lot of time on VT52, VT100, and VT2xx terminals. All DEC terminals have a "delete" or "rub out" key, which transmits 0177. VT52 and VT100 also have a backspace key, which transmits 010. VT2xx (LK201 keyboard) do not have that key. Or rather, they do have a top row function key that is sometimes labeled BS but it sends an escape sequence, and is not taken seriously by most DEC programmers. DEC software convention always was that the delete/rubout key is how you erase the previous character. Backspace was never used for that, and there wasn't any obvious reason to have it on the keyboard. It is, of course, an output formatting character. paul
Re: 9.1: boot-time delay? [WORKAROUND FOUND]
> On May 27, 2021, at 4:14 PM, Robert Elz wrote: > > ... > While changing ms to us is probably a good idea, when a change happens, > the "hz" part should be changed too. > > hz is (a unit of) a measure of frequency, ms (or us) is (a unit of) a > measure of time (duration) - converting one to the other makes no sense. In this particular case it's converting frequency to period, that is a sensible conversion. You could say "hztoperiodinus" but that's rather verbose. paul
Re: regarding the changes to kernel entropy gathering
> On Apr 6, 2021, at 2:21 PM, Martin Husemann wrote: > > > [EXTERNAL EMAIL] > > On Tue, Apr 06, 2021 at 10:54:51AM -0700, Greg A. Woods wrote: >> Except it seems to be useless in practice without an initial seed, > > Yes. > >> And the stock implementation has no possibility of ever providing an >> initial seed at all on its own (unlike previous implementations, and of >> course unlike what my patch _affords_). > > Isn't it as simple as: > > dd bs=32 if=/dev/urandom of=/dev/random > > ? That runs the risk of people thinking it adds entropy. I'd be more comfortable with this: dd bs=32 if=/dev/zero of=/dev/random because it makes the security implications more obvious. paul
Re: regarding the changes to kernel entropy gathering
> On Apr 6, 2021, at 1:54 PM, Greg A. Woods wrote: > > At Mon, 5 Apr 2021 23:18:55 -0400, Thor Lancelot Simon wrote: > Subject: Re: regarding the changes to kernel entropy gathering >> >>> dd if=/dev/urandom of=/dev/random bs=32 count=1 >> >> It's no better. > > So then I would say that in fact using some less trustworthy source of > randomness (e.g. environmental sensors (including audio), clock skew, > disk rotational latency, etc., even network jitter if there is no other > source) as the initial seed entropy _is_ better, for most situations, > and perhaps for _ALL_ situations where no hardware-RNG is available or > possible. Better in part because it prevents the brain-dead way of > seeding, but also because it mixes real-world data in an algorithmically > sound way. I've pointed out in the past that mixing in more external stuff can't make the RNG any worse, assuming it was correctly designed to begin with. So if you still in various external inputs, the worst that can happen is that you get no useful added entropy. In my way of thinking, externals events timestamped with a high resolution (microsecond or better) system clock are likely to have at least a small amount of entropy. It's certainly true that external inputs may be observable, but the nanosecond timestamp the system puts on the packet isn't predictable from the outside (the low order couple of bits, that is). paul
Re: Reparenting processes?
> On Dec 8, 2020, at 8:01 AM, i...@netbsd.org wrote: > > > [EXTERNAL EMAIL] > > On Mon, Dec 07, 2020 at 08:54:33PM -0500, Mouse wrote: >> I've been thinking about building a way to move a job between shells, >> in particular between one window, ssh session, whatever, and another. > > Yes, I've somehow missed the VMS virtual terminals, that can detach > their job from the real terminal and be reattached by a login process, > instead of creating a new job. I didn't know that VMS had this, but certainly you can find that feature in the DEC PDP-11 operating system RSTS/E. And that may have been borrowed from older OSs like TSS-8 or TOPS-10. One complication I can think of: what happens to the original parent process wait for child exit syscall, if the child detaches? I assume it returns; does it return with a new completion value that means "the process isn't actually done but it detached"? Similarly, how does the new parent learn about the new child, and can it then wait for it? paul
