search for: __n

...(__v) : "dN"(__p)); + return __v; +} + +static __inline__ __u32 inl(__u16 __p) +{ + __u32 __v; + asm volatile ("inl %1,%0" : "=a" (__v) : "dN"(__p)); + return __v; +} + +/* String I/O macros */ + +static __inline__ void outsb(__u16 __p, const void *__d, __u64 __n) +{ + asm volatile ("cld; rep; outsb" + : "+S" (__d), "+c"(__n) + : "d"(__p)); +} + +static __inline__ void outsw(__u16 __p, const void *__d, __u64 __n) +{ + asm volatile ("cld; rep; outsw" + : "+S" (__d), "+c"(__n...

...t */ + +#undef _syscall0 +#undef _syscall1 +#undef _syscall2 +#undef _syscall3 +#undef _syscall4 +#undef _syscall5 +#undef _syscall6 + +#define _syscall0(type,name) \ +type name (void) \ +{ \ +long __res; \ +__asm__ volatile (__syscall \ + : "=a" (__res) \ + : "0" (__NR_##name) \ + : __syscall_clobber); \ +__syscall_return(type,__res); \ +} + +#define _syscall1(type,name,type1,arg1) \ +type name (type1 arg1) \ +{ \ +long __res; \ +__asm__ volatile (__syscall \ + : "=a" (__res) \ + : "0" (__NR_##name),"D" (arg1) \...

...son for the difference? diff -p -purN klibc-0.186/include/stdio.h klibc-0.186.fwrite/include/stdio.h --- klibc-0.186/include/stdio.h 2004-07-28 23:09:59.000000000 +0200 +++ klibc-0.186.fwrite/include/stdio.h 2004-10-19 20:06:30.000000000 +0200 @@ -90,7 +90,7 @@ fread(void *__p, size_t __s, size_t __n, } extern __inline__ size_t -fwrite(void *__p, size_t __s, size_t __n, FILE *__f) +fwrite(const void *__p, size_t __s, size_t __n, FILE *__f) { return _fwrite(__p, __s*__n, __f)/__s; } -- USB is for mice, FireWire is for men! sUse lINUX ag, n?RNBERG

...b/libc.so.7 #1 0x000000080136ecd1 in malloc_usable_size () from /lib/libc.so.7 #2 0x000000080136eec7 in free () from /lib/libc.so.7 #3 0x00000000007cdf7d in deallocate (this=0xd2e178, __p=0xd561c0) at new_allocator.h:97 #4 0x00000000007cdfaf in _M_deallocate (this=0xd2e178, __p=0xd561c0, __n=4) at stl_vector.h:134 #5 0x00000000007d66ef in _M_fill_insert (this=0xd2e178, __position= {_M_current = 0xd56380}, __n=1, __x=@0x7fffffffdbb0) at vector.tcc:381 #6 0x00000000007d676d in insert (this=0xd2e178, __position= {_M_current = 0xd56380}, __n=1, __x=@0x7fffffffdbb0) a...

...:MachineInstr>::getNext ( N=0x5a5a5a5a) at MachineBasicBlock.h:37 #1 0x0854d807 in llvm::ilist_iterator<llvm::MachineInstr>::operator-- ( this=0xbfbfe880) at ilist:137 #2 0x085502c5 in std::__advance<llvm::ilist_iterator<llvm::MachineInstr>, int> (__i=@0xbfbfe880, __n=0) at stl_iterator_base_funcs.h:145 #3 0x08550311 in std::advance<llvm::ilist_iterator<llvm::MachineInstr>, int> ( __i=@0xbfbfe880, __n=-1) at stl_iterator_base_funcs.h:177 #4 0x08550339 in llvm::prior<llvm::ilist_iterator<llvm::MachineInstr> > (it= {<bidirect...

...h/i386/crt0.S | 31 +++++++ usr/klibc/arch/i386/libgcc/__ashldi3.S | 29 +++++++ usr/klibc/arch/i386/libgcc/__ashrdi3.S | 29 +++++++ usr/klibc/arch/i386/libgcc/__lshrdi3.S | 29 +++++++ usr/klibc/arch/i386/libgcc/__muldi3.S | 34 ++++++++ usr/klibc/arch/i386/libgcc/__negdi2.S | 21 +++++ usr/klibc/arch/i386/open.S | 29 +++++++ usr/klibc/arch/i386/openat.S | 26 ++++++ usr/klibc/arch/i386/setjmp.S | 58 ++++++++++++++ usr/klibc/arch/i386/sigreturn.S | 15 ++++ usr/klibc/arch/i386/socketcall.S |...

...we don't have a C library - we use whatever is provided by the system we're running on, so that's not really an option. For my testing, I changed libc++'s <cstring> header: -using ::memcpy; +inline _LIBCPP_INLINE_VISIBILITY +void* memcpy(void* __s1, const void* __s2, size_t __n) __attribute__((nonnull(1, 2))) +{ return ::memcpy(__s1, __s2, __n); } (similarly for memmove and memcmp), and I found several cases of simple code that now UBSAN fires off on: such as: std::vector<int> v; v.push_back(1); and : int *p = NULL; std::copy(p,p,p); This seems fair...

Thank You.. I am observing memory allocation instructions malloc and new operator in LLVM IR. In my considered benchmark memory is allocated using new operator as follows. *return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));* How can I observe such allocations in IR? I mean which instruction in IR is equivalent to above code i.e new operator. Please help Thank You On Sun, Jan 6, 2019 at 4:32 AM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > On Sat, Jan 5, 2019 at 3:08 PM hameeza a...

...       from /usr/src/asterisk-16.9.0/include/asterisk.h:22,                  from app_osplookup.c:37: /usr/include/x86_64-linux-gnu/bits/stdio2.h:67:10: note: ‘__builtin___snprintf_chk’ output 4 or more bytes (assuming 259) into a destination of size 256    return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~         __bos (__s), __fmt, __va_arg_pack ()); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ app_osplookup.c:1013:35: warning: ‘]’ directive output may be truncated writing 1 byte into a region of size between 0 and 25...

On Tue, Sep 18, 2007 at 06:41:38PM +1000, Emil Mikulic wrote: > The "make check" produced: > === Summary === > > # of expected passes 2209 > # of unexpected failures 41 > # of expected failures 5 > gmake[1]: *** [check-local] Error 1 > gmake[1]: Leaving directory `/home/emil/ll/objdir-llvm/test' > gmake: ***

...ftell __extern int ferror(FILE * ); +__extern int ferror_unlocked(FILE * ); __extern int feof(FILE *); +__extern int feof_unlocked(FILE *); __extern int fileno(FILE *); +__extern int fileno_unlocked(FILE *); __extern void clearerr(FILE *); +__extern void clearerr_unlocked(FILE *); #ifndef __NO_STDIO_INLINES __extern_inline size_t @@ -104,33 +118,39 @@ fread(void *__p, size_t __s, size_t __n, FILE * __f) { return _fread(__p, __s * __n, __f) / __s; } +#define fread_unlocked(p, s, n, f) fread((p), (s), (n), (f)) __extern_inline size_t fwrite(const void *__p, size_t __s, size_t __n...

...80136ecd1 in malloc_usable_size () from /lib/libc.so.7 > #2 0x000000080136eec7 in free () from /lib/libc.so.7 > #3 0x00000000007cdf7d in deallocate (this=0xd2e178, __p=0xd561c0) > at new_allocator.h:97 > #4 0x00000000007cdfaf in _M_deallocate (this=0xd2e178, __p=0xd561c0, > __n=4) > at stl_vector.h:134 > #5 0x00000000007d66ef in _M_fill_insert (this=0xd2e178, __position= > {_M_current = 0xd56380}, __n=1, __x=@0x7fffffffdbb0) at > vector.tcc:381 > #6 0x00000000007d676d in insert (this=0xd2e178, __position= > {_M_current = 0xd56380},...

Hi, OpenSSH 7.9p1 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This is a bugfix release. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable OpenSSH is also available via git using the instructions at

...::ValueRef*>::_Deque_iterator ( __x=<error reading variable: Cannot access memory at address 0xb0>, this=<synthetic pointer>) at /usr/include/c++/8/bits/stl_deque.h:1401 #1 std::_Deque_iterator<nv50_ir::ValueRef, nv50_ir::ValueRef&, nv50_ir::ValueRef*>::operator+ (__n=0, this=0xb0) at /usr/include/c++/8/bits/stl_deque.h:230 #2 std::_Deque_iterator<nv50_ir::ValueRef, nv50_ir::ValueRef&, nv50_ir::ValueRef*>::operator[] (__n=0, this=0xb0) at /usr/include/c++/8/bits/stl_deque.h:247 #3 std::deque<nv50_ir::ValueRef, std::allocator<nv50_ir::ValueRef&g...

Hi, OpenSSH 8.1p1 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This is a bugfix release. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable OpenSSH is also available via git using the instructions at

First off, thanks -- this is a pretty great library and it feels like I'm learning a lot. I'm getting some more experience with libfuzzer and finding that I have a couple of questions: - How does libfuzzer decide to write a new test file? What distinguishes this one from all the other cases for which new test inputs were not written? Must be something about the path taken through the

...x, const char *format, ...) >>>? ? ???^ >>> In file included from compat.c:3:0: >>> F:/MinGW64/x86_64-w64-mingw32/include/stdio.h:553:5: note: previous >>> definition of 'snprintf' was here >>>???int snprintf (char * __restrict__ __stream, size_t __n, const char * >>> __restrict__ __format, ...) >>>? ? ???^ >>> compat.c:75:5: error: redefinition of 'vsnprintf' >>>???int vsnprintf(char *buffer, size_t bufferSize, const char *format, >>> va_list args) >>>? ? ???^ >>> In file i...

.../testing/testing_install//lib/libc++.so.1 #12 0x00007f76e14dfd05 in operator new[](unsigned long) () from /home/brian/tmp/testing/testing_install//lib/libc++.so.1 #13 0x000000000054bd70 in std::__1::basic_filebuf<char, std::__1::char_traits<char> >::setbuf (this=0x7fffd956b268, __s=0x0, __n=4096) #14 0x00000000005562be in std::__1::basic_filebuf<char, std::__1::char_traits<char> >::basic_filebuf (this=0x7fffd956b268) #15 0x00000000005409e5 in basic_ofstream (this=0x7fffd956b260, __s=..., __mode=16) at /home/brian/tmp/testing/testing_install/bin/../include/c++/v1/fstream:11...

...=0x5a5a5a5a) at MachineBasicBlock.h:37 > #1 0x0854d807 in > llvm::ilist_iterator<llvm::MachineInstr>::operator-- ( > this=0xbfbfe880) at ilist:137 > #2 0x085502c5 in > std::__advance<llvm::ilist_iterator<llvm::MachineInstr>, int> > (__i=@0xbfbfe880, __n=0) at stl_iterator_base_funcs.h:145 > #3 0x08550311 in > std::advance<llvm::ilist_iterator<llvm::MachineInstr>, int> ( > __i=@0xbfbfe880, __n=-1) at stl_iterator_base_funcs.h:177 > #4 0x08550339 in > llvm::prior<llvm::ilist_iterator<llvm::MachineInstr>...

On May 25, 2008, at 1:39 PM, Marcel Moolenaar wrote: > On May 25, 2008, at 12:58 AM, Bill Wendling wrote: > >> Could you try this (massively hacky) patch out to see if it fixes >> your >> problem? >> >> > Alas, it didn't fix the problem: > Crumbs. I think that the analysis I told you before wasn't fully correct. I think I mentioned something