search for: cherie

On 22 Jul 2016, at 07:14, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Just tried to set it up there: https://github.com/joker-eph/llvm-unified > (git log —follow is working fine with this setup). > > While it preserves the history fine (I.e. the hashes are identical to the current git), it has a drawback: there isn’t anymore a common ancestor for the

Well shoot, you beat me to it. :) I've been working on a similar tool but it's not ready yet. Looking forward to trying yours! -David James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> writes: > I'm about to post exactly this tool -- I've been testing it on the > CHERI forks of llvm/clang/lld (lots of history and merges and stuff

> On Jul 22, 2016, at 7:28 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> On Jul 22, 2016, at 12:31 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: >> >> On 22 Jul 2016, at 07:14, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Just tried to set it up there:

Hello all, I recently finished merging the last 3.5 months of upstream changes into our CHERI LLVM fork and would like to suggest something to both simplify our future merges and also avoid bugs for targets such as AVR that use non-zero pointer address spaces. We make extensive use of address spaces: all our pointers (CHERI capabilities) use address space 200 instead of the default zero to

I just want to point out that the issue of incompatible history is not new. This has been getting discussed all the way back in July 2016. http://lists.llvm.org/pipermail/llvm-dev/2016-July/102657.html <http://lists.llvm.org/pipermail/llvm-dev/2016-July/102657.html> As James said in that email: > That we'll be getting incompatible history has been glossed over, and it is >

On 17 Mar 2015, at 13:11, Tyro Software <softwaretyro at gmail.com> wrote: > > As an alternative to fixing the "char == 8 bits" presumption would using non-uniform pointer types have been another possible approach, e.g. keep char as 8 bit but have char* encode both the word address and the byte location within it (i.e. one extra bit in this 16-bit case). Of course this is

Hi, Thanks for starting this discussion Justin! On 10/31/18 5:22 PM, Justin Bogner via llvm-dev wrote: > Hi all, > > I've spent some time in the last couple of days trying to figure out how > to adopt the [LLVM git monorepo prototype] for an out of tree backend. > TLDR: I'm not convinced that this prototype is the right approach to > converting to the monorepo, and I

I agree, improving this makes sense. Alexander, I don’t think that “LLVM_DEFAULT_AS_PARAM” is the right way to go, I would just remove the “ = 0” default parameter entirely. -Chris > On Jul 23, 2020, at 11:02 AM, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Alex, > > I'd be very much in favor of this, thanks for pushing ;) > > On Wed,

OK, I just took my first non-root user live on my Samba 3.0.7 system. Printing is via cups, with drivers stored in the print$ share. This user is a local power user. She can add printers, or root can add them. Root can also print from them. If this user tries to print anything (a test page even) she gets a non-verbose error that looks like a permissions error. She can view the queues

> On Jul 19, 2016, at 09:52, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The IR disruptions for CHERI aren’t that major (the main thing is that we allow alloca’s in different address spaces, but that’s not too difficult to upstream), but it does fail to tick one box that you didn’t list: We would like this feature upstreamed -Matt -------------- next part

...work - DSL Markus@home - DSL Randy@home - cable Josh - dialup, 45/26 Grig - dialup 28.8/22.6 Jeff@work - dsl Jeff@dialup - 33/20 Keena@home - dialup 48/33.1 Kellie@aol - dialup 33/19 am@home - dialup 48/37 (no icecast test yet. ) am@home - dialup ?/? (icecast, didn't get speed test) cherie@home dialup 48/41 <p><p>The pattern is: anyone with a broadband connection can connect and stay connected for hours. Anyone but Cherie with a dialup can connect, load up the buffer in about 10 seconds, listen for about 2 min, and then get dropped. The last 30 seconds are very traumati...

LLVM makes several assumptions about address space 0. However, alloca is presently constrained to always return this address space. There's no real way to avoid using alloca, so without this there is no way to opt out of these assumptions. The problematic assumptions include: * That the pointer size used for the stack is the same size as the code size pointer, which is also the

Hi I want to pursue a project based to improve the existing KCoFI method which is the Control Flow integrity method for commodity os. Since KCoFI is a llvm based project I plan to undertake the project to improve the existing KCoFI method. Following are the improvements that I want to pursue: 1. To improve the call graph used in KCoFI. Implement a stronger call graph. 2. Port the KCoFI to

I am a newbie to samba. I have successfully setup a similar samba share on 1 machine in the past. I have everything setup as User access with the pcguest as a guest account. If I create a share to the /tmp, network users can access normally. I created a directory /var/snd and set permissions to be rwxrwxrwx. I changed the smb.conf so that permission were identical to the share for /tmp. I

On 19 July 2016 at 17:04, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Presumably if my out-of-tree backend was to be pushed to LLVM, it too would be considered experimental. Yes. Though, not all out-of-tree back-ends end up upstream for different reasons. A few basic rules to get accepted are if: * the target exists and can be easily purchased / emulated

On Fri, 7 Sep 2018 at 17:48, Tim Northover <t.p.northover at gmail.com> wrote: > I looked at your diffs and you've only changed one of the functions to > return SDValue(), you need to change lowerFP_TO_SINT itself too. The > one with the store is just there as an optimization; if it doesn't > trigger (because of your diff) then lowerFP_TO_SINT will still create > a

> I might be missing your point here - but don't forget that the local globals are always PC-relative direct loads/stores. I did forget! Thanks for clarifying, now I understand. On Fri, 18 Sep 2020 at 20:51, Evgenii Stepanov <eugenis at google.com> wrote: > > > > On Fri, Sep 18, 2020 at 12:18 PM Mitch Phillips via llvm-dev <llvm-dev at lists.llvm.org> wrote:

.../samba/log.%m max log size = 50 socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=8192 SO_SNDBUF=8192 SO_KEEPALIVE preferred master = Yes domain master = No dns proxy = No guest account = [Oracle] path = /home/oracle valid users = cherie,devinb,admin,mshepard,equser,hjg,dianew,accounting force user = oracle read only = No [Equinox] path = /home/oracle/equinox write list = katherine,cherie,dianew,janice,hjg,sai,accounting force user = oracle [Bills] path = /home/oracle/equinox/Bills...

On 20 Feb 2014, at 06:11, Ivan Godard <ivan at ootbcomp.com> wrote: > It's not just old mainframes, it's some of the newest architecture as well. > The Mill general-purpose architecture (http://ootbcomp.com) has non-integer > pointers and distinct pointer operations too. That LLVM loses pointerhood is > the biggest problem that we have identified while looking into using

https://bugzilla.mindrot.org/show_bug.cgi?id=2704 Bug ID: 2704 Summary: Avoid passing pointers between processes Product: Portable OpenSSH Version: -current Hardware: Other OS: All Status: NEW Severity: enhancement Priority: P5 Component: sshd Assignee: unassigned-bugs at