similar to: named log entries - Are any of these a problem?

All: I'm posting this to FreeBSD-security (rather than FreeBSD-net) because the problems I'm seeing appear to have been caused by spyware, and because they constitute a possible avenue for denial of service on FreeBSD machines with default installs of the operating system. Several of the FreeBSD machines on our network began to act strangely during the past week. Some have started to

Hi, we are running a Samba AD on UCS 4.2, which comes with Samba 4.6.1. The DNS server (192.168.0.200) is operated by bind with the samba DLZ module. It also hosts several zones outside of samba. Every couple of hours, I get messages like these on the server: Jun 5 23:04:58 ucsdc1 daemon:[warning] checkhints: h.root-servers.net/A (198.97.190.53) missing from hints Jun 5 23:04:58 ucsdc1

I have a path: path = "/nfs/users/nfs_n/ns9/ Phenotype Analysis/Results/Run_AmplRatio_neg BinaryAll trained without akapn+tnik.csv" I wish to replace the spaces with "\ " so that it can be read by a system call to unix. Using gsub I try: > gsub(" ","\\ ",path) [1] "/nfs/users/nfs_n/ns9/Phenotype Analysis/Results/Run_AmplRatio_neg BinaryAll

Hi Eli, Thank you very much for your response. In fact, I had already tried the X86 approach before, i.e explicitly using the status register. This is the approach that appeals more to me. I left it parked because it also produced some problems (but I left it commented out). So I have now re-lived the code, and it works fine in most cases, but there’s a particular case that causes LLVM to stop

A quick search on Google gives: http://www.unixfu .ch/how-do-i-update-the-root-hints-data-file-for-bind-named-server/ Best regards, Marcel de Reuver 2017-06-06 11:36 GMT+02:00 Torsten Kurbad via samba <samba at lists.samba.org>: > Hi, > > we are running a Samba AD on UCS 4.2, which comes with Samba 4.6.1. > > The DNS server (192.168.0.200) is operated by bind with the samba

Hi Eli, Thanks again for your reply. I am unsure about implementing the getCrossCopyRegClass for my target. My target does not support or allow moves to and from the SR. The SR exists because it has implicit involvement in some instructions, but it is opaque to the assembler and to the user as a register. I mean, there are no instructions to directly move or read it, or even access it directly.

Hi, Let me try to clear some confusion. On Tue, Jun 6, 2017 at 7:36 PM, Torsten Kurbad via samba < samba at lists.samba.org> wrote: > Hi, > > we are running a Samba AD on UCS 4.2, which comes with Samba 4.6.1. > > The DNS server (192.168.0.200) is operated by bind with the samba DLZ > module. It also hosts several zones outside of samba. > > Every couple of hours,

Hi all, Our target does not have native support for 64-bit integers, so we rely on library calls for certain operations (like sdiv). We recently ran into a problem where these operations that are expanded to library calls aren't maintaining the proper ordering in relation to other chains in the DAG. The following snippet of a DAG demonstrates the problem. t0: ch = EntryToken t2:

Here is a last example to illustrate my concern. The problem is about the lowering of node t13. Initial selection DAG: BB#0 '_start:entry' SelectionDAG has 44 nodes: t11: i16 = Constant<0> t0: ch = EntryToken t3: ch = llvm.clp.set.rspa t0, TargetConstant:i16<392>, Constant:i32<64> t5: ch = llvm.clp.set.rspb t3,

The DAG dumping will try to print some of the nodes "inline" (i.e. where they are used) to make the output more readable, so the dump of the DAG may not strictly reflect the node ordering. -Krzysztof On 5/4/2018 8:18 AM, Dominique Torette via llvm-dev wrote: > Here is a last example to illustrate my concern. > > The problem is about the lowering of node t13. > >

Krzysztof, Thanks for your interest to my questions. In order to clarify the context, here is the C source file of my test case. The 3 builtins initialize some stack pointers. They have to be executed before any other instruction. extern float fdivfaddfmul_a(float a, float b, float c, float d); volatile static float x1,x2,x3,x4; void _start(void) { float res;

Would it not make sense to refactor the code so those don't use glue rather than emitting them with glue and then getting rid of it. There are times when we would like to emit these in separate blocks but can't (presumably because of the glue). On Tue, Feb 7, 2017 at 9:15 PM, James Y Knight via llvm-dev < llvm-dev at lists.llvm.org> wrote: > That's seems really odd that

I'd think i1 would be the proper and correct choice for a carry flag for the generic instruction. I expect that would also make UADDO/USUBO redundant with ADDC/SUBC (which would seem a good outcome). You'd need to make sure the right thing happened when converting from ADDC's 1-bit carry in/out to X86ISD::AD[DC]'s EFLAGS i/o. Right now the conversion can get away with assuming

I don't think that'd work, because it leaves all other backends broken. AFAICT, your transform is simply not a legal transform, with the way the ADDC/ADDE opcodes are currently defined, and to do it you really need to fix the opcode definitions to not involve glue, first. I also note that your transform doesn't actually trigger at all on this particular test case on x86, because the

Hi LLVM-Devs, I have managed to complete updating our sources from LLVM v4.0 to v5.0, but I am getting selection errors for 'callseq_end'. I am aware that the 'ADJCALLSTACKUP' and 'ADJCALLSTACKDOWN' patterns have changed, and have added an additional argument to the TD descriptions for these. There are interactions with 'ISD::CALL' and 'ISD::RET_FLAG',

Hi guys I got the errors like this while compiling cluster glue: ./.libs/libplumb.so: undefined reference to `uuid_parse' ./.libs/libplumb.so: undefined reference to `uuid_generate' ./.libs/libplumb.so: undefined reference to `uuid_copy' ./.libs/libplumb.so: undefined reference to `uuid_is_null' ./.libs/libplumb.so: undefined reference to `uuid_unparse'

I attempt to optimize the use of the ‘CMP’ instruction on my architecture by removing the instruction instances where the Status Register already had the correct status flags. The cmp instruction in my architecture is the typical one that compares two registers, or a register with an immediate, and sets the Status Flags accordingly. I implemented my ‘cmp’ instruction in LLVM by custom lowering

The log message for revision 122213 says: > Change the X86 backend to stop using the evil ADDC/ADDE/SUBC/SUBE nodes (which > their carry depenedencies with MVT::Flag operands) and use clean and beautiful > EFLAGS dependences instead. (MVT::Flag has since been renamed to MVT::Glue.) That revision made bug 8404 go away. Am I right in thinking that one of the problems with MVT::Glue is

Hi Jakob, Jonas et al, Jakob wrote: [...] > Jonas wrote: > [...] > > What's more, setting the GPR_CR class to 'not-spillable' would probably do the trick here as we > > basically do not want to do this, and I would not have to pre-allocate. But there is probably a > > better way, or? > > I am sorry, I simply don't understand what you are asking

newbee here. What's the difference between glue and chain? Why can't we add chains to any node we want? On Fri, Jul 17, 2020, 10:25 PM Björn Pettersson A via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Still sounds to me as Glue might help (as already proposed by Craig), but > maybe I’ve misunderstood something. > > > > Another option is to do a simple