Gsoc improvement for next time

2020-05-04 Thread suyash singh
Hello, unfortunately I did not get accepted to gsoc 2020. May I know how
can I improve for next time?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: clang sparc: generated .o file incompatible with elf64-x86-64

2020-05-04 Thread suyash singh
>
> Have you seen that?
>
> https://stackoverflow.com/questions/19118854/unable-to-cross-compile-to-sparc-using-clang
> I’m not sure sparc backend is well supported by clang/llvm. Try with
> riscv.


Yes I saw. It is old post, I have clang 11 and it is detecting sparc as a
target so I thought clang supports sparc

I am trying with riscv, clang riscv files are missing so I need to fix. I
got same issue with UBSan initially and fixed it by pasting UBSan files in
correct location(clang puts them in wrong location)

I am documenting everything here
https://github.com/suyashsingh234/rtems-notes/blob/master/README.md

On Mon, May 4, 2020 at 9:41 PM suyash singh 
wrote:

> with sparc-unknown-rtems5
>
> clang version 11.0.0 (https://github.com/llvm/llvm-project.git
> 05606329e2353e37492bcf567ab4a4b27bceb65c)
> Target: sparc-unknown-rtems5
> Thread model: posix
> InstalledDir: /home/suyash/Desktop/clanganalyzer/llvm-project/build2/bin
>  "/home/suyash/Desktop/clanganalyzer/llvm-project/build2/bin/clang-11"
> -cc1 -triple sparc-unknown-rtems5 -emit-obj -mrelax-all -disable-free
> -main-file-name test1.c -mrelocation-model static -mthread-model posix
> -mframe-pointer=all -fmath-errno -fno-rounding-math -mconstructor-aliases
> -mfloat-abi hard -dwarf-column-info -fno-split-dwarf-inlining
> -debugger-tuning=gdb -v -resource-dir
> /home/suyash/Desktop/clanganalyzer/llvm-project/build2/lib/clang/11.0.0
> -fdebug-compilation-dir /home/suyash/Desktop/clangtest -ferror-limit 19
> -fmessage-length 0
> -fsanitize=alignment,array-bounds,bool,builtin,enum,float-cast-overflow,integer-divide-by-zero,nonnull-attribute,null,pointer-overflow,return,returns-nonnull-attribute,shift-base,shift-exponent,signed-integer-overflow,unreachable,vla-bound
> -fsanitize-recover=alignment,array-bounds,bool,builtin,enum,float-cast-overflow,integer-divide-by-zero,nonnull-attribute,null,pointer-overflow,returns-nonnull-attribute,shift-base,shift-exponent,signed-integer-overflow,vla-bound
> -fgnuc-version=4.2.1 -fobjc-runtime=gcc -fdiagnostics-show-option
> -fcolor-diagnostics -faddrsig -o /tmp/test1-ffe267.o -x c test1.c
> clang -cc1 version 11.0.0 based upon LLVM 11.0.0git default target
> x86_64-unknown-linux-gnu
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/local/include
>
>  
> /home/suyash/Desktop/clanganalyzer/llvm-project/build2/lib/clang/11.0.0/include
> End of search list.
>  "/usr/bin/gcc" -fuse-ld=lld -fsanitize=undefined -v -o a.out
> /tmp/test1-ffe267.o
> Using built-in specs.
> COLLECT_GCC=/usr/bin/gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
> --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
> --with-gcc-major-version-only --program-suffix=-7
> --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-vtable-verify --enable-libmpx --enable-plugin
> --enable-default-pie --with-system-zlib --with-target-system-zlib
> --enable-objc-gc=auto --enable-multiarch --disable-werror
> --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
> --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
> --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
>
> COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/
>
> LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/
> COLLECT_GCC_OPTIONS='-fuse-ld=lld' '-fsanitize=undefined' '-v' '-o'
> 'a.out' '-mtune=generic' '-march=x86-64'
>  /usr/lib/gcc/x86_64-linux-gnu/7/collect2 -plugin
> /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so
> -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
> -plugin-opt=-fresolution=/tmp/ccJfTl2s.res -plugin-opt=-pass-through=-lgcc
> -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc

Re: clang sparc: generated .o file incompatible with elf64-x86-64

2020-05-04 Thread suyash singh
collect2: error: ld returned 1 exit status
clang-11: error: linker (via gcc) command failed with exit code 1 (use -v
to see invocation)

On Mon, May 4, 2020 at 9:40 PM suyash singh 
wrote:

> Also can you add -v and send the output?
>
>
> clang version 11.0.0 (https://github.com/llvm/llvm-project.git
> 05606329e2353e37492bcf567ab4a4b27bceb65c)
> Target: sparc
> Thread model: posix
> InstalledDir: /home/suyash/Desktop/clanganalyzer/llvm-project/build2/bin
>  "/home/suyash/Desktop/clanganalyzer/llvm-project/build2/bin/clang-11"
> -cc1 -triple sparc -emit-obj -mrelax-all -disable-free -main-file-name
> test1.c -mrelocation-model static -mthread-model posix -mframe-pointer=all
> -fmath-errno -fno-rounding-math -mconstructor-aliases -mfloat-abi hard
> -dwarf-column-info -fno-split-dwarf-inlining -debugger-tuning=gdb -v
> -resource-dir
> /home/suyash/Desktop/clanganalyzer/llvm-project/build2/lib/clang/11.0.0
> -fdebug-compilation-dir /home/suyash/Desktop/clangtest -ferror-limit 19
> -fmessage-length 0
> -fsanitize=alignment,array-bounds,bool,builtin,enum,float-cast-overflow,integer-divide-by-zero,nonnull-attribute,null,pointer-overflow,return,returns-nonnull-attribute,shift-base,shift-exponent,signed-integer-overflow,unreachable,vla-bound
> -fsanitize-recover=alignment,array-bounds,bool,builtin,enum,float-cast-overflow,integer-divide-by-zero,nonnull-attribute,null,pointer-overflow,returns-nonnull-attribute,shift-base,shift-exponent,signed-integer-overflow,vla-bound
> -fgnuc-version=4.2.1 -fobjc-runtime=gcc -fdiagnostics-show-option
> -fcolor-diagnostics -faddrsig -o /tmp/test1-6da71f.o -x c test1.c
> clang -cc1 version 11.0.0 based upon LLVM 11.0.0git default target
> x86_64-unknown-linux-gnu
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/local/include
>
>  
> /home/suyash/Desktop/clanganalyzer/llvm-project/build2/lib/clang/11.0.0/include
>  /usr/include
> End of search list.
>  "/usr/bin/gcc" -fuse-ld=lld -fsanitize=undefined -v -o a.out
> /tmp/test1-6da71f.o
> Using built-in specs.
> COLLECT_GCC=/usr/bin/gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
> --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
> --with-gcc-major-version-only --program-suffix=-7
> --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-vtable-verify --enable-libmpx --enable-plugin
> --enable-default-pie --with-system-zlib --with-target-system-zlib
> --enable-objc-gc=auto --enable-multiarch --disable-werror
> --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
> --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
> --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
>
> COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/
>
> LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/
> COLLECT_GCC_OPTIONS='-fuse-ld=lld' '-fsanitize=undefined' '-v' '-o'
> 'a.out' '-mtune=generic' '-march=x86-64'
>  /usr/lib/gcc/x86_64-linux-gnu/7/collect2 -plugin
> /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so
> -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
> -plugin-opt=-fresolution=/tmp/ccrvaAg0.res -plugin-opt=-pass-through=-lgcc
> -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
> -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
> --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed
> -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -fuse-ld=lld -z
> relro -o a.out
> /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o
> /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o
> /usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o
> -L/usr/lib/gcc/x86_64-linux-gnu/7
> -L/usr/lib/gcc/

Re: clang sparc: generated .o file incompatible with elf64-x86-64

2020-05-04 Thread suyash singh
x86-64
collect2: error: ld returned 1 exit status
clang-11: error: linker (via gcc) command failed with exit code 1 (use -v
to see invocation)

On Mon, May 4, 2020 at 6:26 PM Hesham Almatary 
wrote:

> Have you seen that?
>
> https://stackoverflow.com/questions/19118854/unable-to-cross-compile-to-sparc-using-clang
>
> I’m not sure sparc backend is well supported by clang/llvm. Try with
> riscv.
>
> On Mon, 4 May 2020 at 13:34, Hesham Almatary 
> wrote:
>
>>
>>
>> On Mon, 4 May 2020 at 13:19, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Mon, May 4, 2020, 7:16 AM suyash singh 
>>> wrote:
>>>
>>>> I am trying to cross compile with clang and run Undefined Behavior
>>>> Sanitizer for .c file
>>>>
>>>> *Command I am running*
>>>>
>>>> clang -target sparc -integrated-as -fuse-ld=lld -fsanitize=undefined 
>>>> test1.c
>>>>
>>>> clang is the cross compiler
>>>>
>>>> sparc is the target architecture.
>>>>
>>>> -integrated-as to use the llvm assembler
>>>>
>>>> -fuse-ld=lld to use lld linker
>>>>
>>>> -fsanitize=undefined to run UBSan
>>>>
>>>> *Error*
>>>>
>>>> ld.lld: error: /tmp/test1-43c7c0.o is incompatible with elf64-x86-64
>>>>
>>>> collect2: error: ld returned 1 exit status
>>>>
>>>> clang-11: error: linker (via gcc) command failed with exit code 1 (use
>>>> -v to see invocation)
>>>>
>>>> *My system*
>>>>
>>>> Ubuntu 18.04
>>>>
>>>> x86_64
>>>>
>>>> command executed on ubuntu terminal
>>>>
>>>> without -target sparc on a file.c which does not contain sparc assembly
>>>> the clang works fine
>>>>
>>>
>>> This is the same problem you had with as. You need to properly specify
>>> the target and have the target as and ld in your PATH.
>>>
>>
>> Also can you add -v and send the output?
>>
>>>
>>> --joel
>>>
>>>> ___
>>>> devel mailing list
>>>> devel@rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

clang sparc: generated .o file incompatible with elf64-x86-64

2020-05-04 Thread suyash singh
I am trying to cross compile with clang and run Undefined Behavior
Sanitizer for .c file

*Command I am running*

clang -target sparc -integrated-as -fuse-ld=lld -fsanitize=undefined test1.c

clang is the cross compiler

sparc is the target architecture.

-integrated-as to use the llvm assembler

-fuse-ld=lld to use lld linker

-fsanitize=undefined to run UBSan

*Error*

ld.lld: error: /tmp/test1-43c7c0.o is incompatible with elf64-x86-64

collect2: error: ld returned 1 exit status

clang-11: error: linker (via gcc) command failed with exit code 1 (use -v
to see invocation)

*My system*

Ubuntu 18.04

x86_64

command executed on ubuntu terminal

without -target sparc on a file.c which does not contain sparc assembly the
clang works fine
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems assembler

2020-05-02 Thread suyash singh
Ok I think I found a solution.

use -integrated-as with clang

clang is using the system assembler(usr/bin/as) instead of the llvm
assembler(llvm-as)

It's still not working but at least assembler command failed error is gone

On Thu, Apr 30, 2020 at 9:36 PM Hesham Almatary 
wrote:

>
>
> On Thu, 30 Apr 2020 at 15:56, suyash singh 
> wrote:
>
>> after adding -v
>> https://hastebin.com/epijunegix.coffeescript
>>
>> with sparc-unknown-elf
>> https://hastebin.com/ijohidofus.coffeescript
>>
>> (target getting an extra unknown for some reason)
>>
>> riscv64-unknown-elf
>> https://hastebin.com/jirusidoti.sql
>>  different error: unknown register name (maybe because erc32 bsp with
>> riscv)
>>
> Yes, you need to run that on an RTEMS riscv BSP and not sparc sources
>
>
>>
>> On Thu, Apr 30, 2020 at 8:08 PM Hesham Almatary 
>> wrote:
>>
>>>
>>>
>>> On Thu, 30 Apr 2020 at 15:21, suyash singh 
>>> wrote:
>>>
>>>> I think it doesn't support sparc backend although it does not give
>>>> unknown target error.
>>>>
>>>> I compiled this c program with
>>>> export PATH=$HOME/quick-start/rtems/5/bin:"$PATH"
>>>>  clang -target sparc-unknown-rtems5 test1.c
>>>>
>>> Can you add -v to that command and post the output? Also try with
>>> sparc-unknown-elf. Last thing to try is to do the same for
>>> riscv64-unknown-elf
>>>
>>>>
>>>> *test1.c*
>>>> int main(int argc, char **argv) {
>>>>   int k = 0x7fff;
>>>>   k += argc;
>>>>   return 0;
>>>> }
>>>>
>>>> same error
>>>> /usr/bin/as: unrecognized option '-Av8'
>>>> clang-11: error: assembler command failed with exit code 1
>>>>
>>>> If i write
>>>> clang -target hello test1.c
>>>> error: unknown target triple 'hello', please use -triple or -arch
>>>>
>>>> So I guess it is detecting sparc but not working with it
>>>>
>>>> On Thu, Apr 30, 2020 at 7:07 PM Hesham Almatary <
>>>> heshamelmat...@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, 30 Apr 2020 at 14:18, suyash singh 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> I am using ubuntu 18.04 terminal
>>>>>>
>>>>>> Here's the python script I wrote to find all include files and run
>>>>>> clang -fsanitize
>>>>>>
>>>>>> # run with python3 in terminal
>>>>>>
>>>>>> import subprocess
>>>>>> import os
>>>>>>
>>>>>> relativedir="../bsps/sparc/erc32/btimer"
>>>>>> directory=os.path.join(os.getcwd(),"../")
>>>>>> file="btimer.c"
>>>>>> root_dir="ubsan"
>>>>>>
>>>>>> arr=['clang','-target','sparc','-
>>>>>>
>>>>> target needs to be sparc-unknown-rtems5 to pick up the correct tools.
>>>>> Does your clang support sparc backend? Can you try to compile and link 
>>>>> some
>>>>> simple C program with it?
>>>>>
>>>>>
>>>>>> fsanitize=undefined',"-I../../../../../../rtems/5/sparc-rtems5/erc32/lib/include","-I../../../../../../rtems/5/sparc-rtems5/include/"]
>>>>>>
>>>>>> for path, subdirs, files in os.walk(directory):
>>>>>> for subdir in subdirs:
>>>>>> if(subdir=="include"):
>>>>>> includepath=os.path.join(path,subdir)
>>>>>> idx=includepath.find("..")
>>>>>> arr.append("-I../../../../"+includepath[idx+3:])
>>>>>> arr.append(file)
>>>>>> subprocess.run(arr,cwd=relativedir, stdout=subprocess.PIPE)
>>>>>> #result=subprocess.run(['./a.out'],cwd=relativedir,
>>>>>> stdout=subprocess.PIPE)
>>>>>>
>>>>>> On Thu, Apr 30, 2020 at 6:44 PM Hesham Almatary <
>>>>>> heshamelmat...@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, 30 Apr 2020 at 13:51, Joel Sherrill  wrote:
>>>>>>>
>>>>>

Re: rtems assembler

2020-04-30 Thread suyash singh
after adding -v
https://hastebin.com/epijunegix.coffeescript

with sparc-unknown-elf
https://hastebin.com/ijohidofus.coffeescript

(target getting an extra unknown for some reason)

riscv64-unknown-elf
https://hastebin.com/jirusidoti.sql
 different error: unknown register name (maybe because erc32 bsp with
riscv)


On Thu, Apr 30, 2020 at 8:08 PM Hesham Almatary 
wrote:

>
>
> On Thu, 30 Apr 2020 at 15:21, suyash singh 
> wrote:
>
>> I think it doesn't support sparc backend although it does not give
>> unknown target error.
>>
>> I compiled this c program with
>> export PATH=$HOME/quick-start/rtems/5/bin:"$PATH"
>>  clang -target sparc-unknown-rtems5 test1.c
>>
> Can you add -v to that command and post the output? Also try with
> sparc-unknown-elf. Last thing to try is to do the same for
> riscv64-unknown-elf
>
>>
>> *test1.c*
>> int main(int argc, char **argv) {
>>   int k = 0x7fff;
>>   k += argc;
>>   return 0;
>> }
>>
>> same error
>> /usr/bin/as: unrecognized option '-Av8'
>> clang-11: error: assembler command failed with exit code 1
>>
>> If i write
>> clang -target hello test1.c
>> error: unknown target triple 'hello', please use -triple or -arch
>>
>> So I guess it is detecting sparc but not working with it
>>
>> On Thu, Apr 30, 2020 at 7:07 PM Hesham Almatary 
>> wrote:
>>
>>>
>>>
>>> On Thu, 30 Apr 2020 at 14:18, suyash singh 
>>> wrote:
>>>
>>>>
>>>> I am using ubuntu 18.04 terminal
>>>>
>>>> Here's the python script I wrote to find all include files and run
>>>> clang -fsanitize
>>>>
>>>> # run with python3 in terminal
>>>>
>>>> import subprocess
>>>> import os
>>>>
>>>> relativedir="../bsps/sparc/erc32/btimer"
>>>> directory=os.path.join(os.getcwd(),"../")
>>>> file="btimer.c"
>>>> root_dir="ubsan"
>>>>
>>>> arr=['clang','-target','sparc','-
>>>>
>>> target needs to be sparc-unknown-rtems5 to pick up the correct tools.
>>> Does your clang support sparc backend? Can you try to compile and link some
>>> simple C program with it?
>>>
>>>
>>>> fsanitize=undefined',"-I../../../../../../rtems/5/sparc-rtems5/erc32/lib/include","-I../../../../../../rtems/5/sparc-rtems5/include/"]
>>>>
>>>> for path, subdirs, files in os.walk(directory):
>>>> for subdir in subdirs:
>>>> if(subdir=="include"):
>>>> includepath=os.path.join(path,subdir)
>>>> idx=includepath.find("..")
>>>> arr.append("-I../../../../"+includepath[idx+3:])
>>>> arr.append(file)
>>>> subprocess.run(arr,cwd=relativedir, stdout=subprocess.PIPE)
>>>> #result=subprocess.run(['./a.out'],cwd=relativedir,
>>>> stdout=subprocess.PIPE)
>>>>
>>>> On Thu, Apr 30, 2020 at 6:44 PM Hesham Almatary <
>>>> heshamelmat...@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, 30 Apr 2020 at 13:51, Joel Sherrill  wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 30, 2020 at 7:34 AM suyash singh <
>>>>>> suyashsingh...@gmail.com> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>> I was running clang UBSan on
>>>>>>> bsps/sparc/erc32/btimer/btimer.c
>>>>>>>
>>>>>>> and got error
>>>>>>>
>>>>>>> /usr/bin/as: unrecognized option '-Av8'
>>>>>>> clang-11: error: assembler command failed with exit code 1
>>>>>>>
>>>>>>> I am not sure but is it because clang is using wrong assembler?
>>>>>>>
>>>>>>
>>>>>> I haven't seen anyone run into this in a long time. :)
>>>>>>
>>>>>> In this case, it is likely one of two things:
>>>>>>
>>>>>> + Look at your $PATH. Make sure the RTEMS tools are first.
>>>>>>
>>>>>> + But in your case, I expect that it is because the clang didn't
>>>>>> know (somehow) to put the target name in front of the as.
>>>>>> Did you invoke it for sparc-rtems5? If so, then there is a
>>>>>> path through clang where it isn't looking at the target name.
>>>>>>
>>>>> That’s likely to be the problem. I expect Suyash isn’t cross compiling
>>>>> with clang.
>>>>>
>>>>>
>>>>>> I also double checked the as manual to ensure -Av8 was in
>>>>>> fact a sparc option.
>>>>>>
>>>>>> --joel
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> devel mailing list
>>>>>>> devel@rtems.org
>>>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>>>
>>>>>> ___
>>>>>> devel mailing list
>>>>>> devel@rtems.org
>>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>>
>>>>> --
>>>>> Hesham
>>>>> ___
>>>>> devel mailing list
>>>>> devel@rtems.org
>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>
>>>> --
>>> Hesham
>>>
>> --
> Hesham
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems assembler

2020-04-30 Thread suyash singh
oh I mean

for target which does not exist like "hello" it says "unknown target"
I wrote that as example to say that
sparc-unknown-rtems5 is detected as valid target but not used

On Thu, Apr 30, 2020 at 7:52 PM Joel Sherrill  wrote:

>
>
> On Thu, Apr 30, 2020 at 9:21 AM suyash singh 
> wrote:
>
>> I think it doesn't support sparc backend although it does not give
>> unknown target error.
>>
>> I compiled this c program with
>> export PATH=$HOME/quick-start/rtems/5/bin:"$PATH"
>>  clang -target sparc-unknown-rtems5 test1.c
>>
>> *test1.c*
>> int main(int argc, char **argv) {
>>   int k = 0x7fff;
>>   k += argc;
>>   return 0;
>> }
>>
>> same error
>> /usr/bin/as: unrecognized option '-Av8'
>> clang-11: error: assembler command failed with exit code 1
>>
>> If i write
>> clang -target hello test1.c
>> error: unknown target triple 'hello', please use -triple or -arch
>>
>
> You left the target name off.
>
> clang -target sparc-unknown-rtems5 hello test1.c
>
>>
>> So I guess it is detecting sparc but not working with it
>>
>> On Thu, Apr 30, 2020 at 7:07 PM Hesham Almatary 
>> wrote:
>>
>>>
>>>
>>> On Thu, 30 Apr 2020 at 14:18, suyash singh 
>>> wrote:
>>>
>>>>
>>>> I am using ubuntu 18.04 terminal
>>>>
>>>> Here's the python script I wrote to find all include files and run
>>>> clang -fsanitize
>>>>
>>>> # run with python3 in terminal
>>>>
>>>> import subprocess
>>>> import os
>>>>
>>>> relativedir="../bsps/sparc/erc32/btimer"
>>>> directory=os.path.join(os.getcwd(),"../")
>>>> file="btimer.c"
>>>> root_dir="ubsan"
>>>>
>>>> arr=['clang','-target','sparc','-
>>>>
>>> target needs to be sparc-unknown-rtems5 to pick up the correct tools.
>>> Does your clang support sparc backend? Can you try to compile and link some
>>> simple C program with it?
>>>
>>>
>>>> fsanitize=undefined',"-I../../../../../../rtems/5/sparc-rtems5/erc32/lib/include","-I../../../../../../rtems/5/sparc-rtems5/include/"]
>>>>
>>>> for path, subdirs, files in os.walk(directory):
>>>> for subdir in subdirs:
>>>> if(subdir=="include"):
>>>> includepath=os.path.join(path,subdir)
>>>> idx=includepath.find("..")
>>>> arr.append("-I../../../../"+includepath[idx+3:])
>>>> arr.append(file)
>>>> subprocess.run(arr,cwd=relativedir, stdout=subprocess.PIPE)
>>>> #result=subprocess.run(['./a.out'],cwd=relativedir,
>>>> stdout=subprocess.PIPE)
>>>>
>>>> On Thu, Apr 30, 2020 at 6:44 PM Hesham Almatary <
>>>> heshamelmat...@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, 30 Apr 2020 at 13:51, Joel Sherrill  wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 30, 2020 at 7:34 AM suyash singh <
>>>>>> suyashsingh...@gmail.com> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>> I was running clang UBSan on
>>>>>>> bsps/sparc/erc32/btimer/btimer.c
>>>>>>>
>>>>>>> and got error
>>>>>>>
>>>>>>> /usr/bin/as: unrecognized option '-Av8'
>>>>>>> clang-11: error: assembler command failed with exit code 1
>>>>>>>
>>>>>>> I am not sure but is it because clang is using wrong assembler?
>>>>>>>
>>>>>>
>>>>>> I haven't seen anyone run into this in a long time. :)
>>>>>>
>>>>>> In this case, it is likely one of two things:
>>>>>>
>>>>>> + Look at your $PATH. Make sure the RTEMS tools are first.
>>>>>>
>>>>>> + But in your case, I expect that it is because the clang didn't
>>>>>> know (somehow) to put the target name in front of the as.
>>>>>> Did you invoke it for sparc-rtems5? If so, then there is a
>>>>>> path through clang where it isn't looking at the target name.
>>>>>>
>>>>> That’s likely to be the problem. I expect Suyash isn’t cross compiling
>>>>> with clang.
>>>>>
>>>>>
>>>>>> I also double checked the as manual to ensure -Av8 was in
>>>>>> fact a sparc option.
>>>>>>
>>>>>> --joel
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> devel mailing list
>>>>>>> devel@rtems.org
>>>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>>>
>>>>>> ___
>>>>>> devel mailing list
>>>>>> devel@rtems.org
>>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>>
>>>>> --
>>>>> Hesham
>>>>> ___
>>>>> devel mailing list
>>>>> devel@rtems.org
>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>
>>>> --
>>> Hesham
>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems assembler

2020-04-30 Thread suyash singh
I think it doesn't support sparc backend although it does not give unknown
target error.

I compiled this c program with
export PATH=$HOME/quick-start/rtems/5/bin:"$PATH"
 clang -target sparc-unknown-rtems5 test1.c

*test1.c*
int main(int argc, char **argv) {
  int k = 0x7fff;
  k += argc;
  return 0;
}

same error
/usr/bin/as: unrecognized option '-Av8'
clang-11: error: assembler command failed with exit code 1

If i write
clang -target hello test1.c
error: unknown target triple 'hello', please use -triple or -arch

So I guess it is detecting sparc but not working with it

On Thu, Apr 30, 2020 at 7:07 PM Hesham Almatary 
wrote:

>
>
> On Thu, 30 Apr 2020 at 14:18, suyash singh 
> wrote:
>
>>
>> I am using ubuntu 18.04 terminal
>>
>> Here's the python script I wrote to find all include files and run clang
>> -fsanitize
>>
>> # run with python3 in terminal
>>
>> import subprocess
>> import os
>>
>> relativedir="../bsps/sparc/erc32/btimer"
>> directory=os.path.join(os.getcwd(),"../")
>> file="btimer.c"
>> root_dir="ubsan"
>>
>> arr=['clang','-target','sparc','-
>>
> target needs to be sparc-unknown-rtems5 to pick up the correct tools. Does
> your clang support sparc backend? Can you try to compile and link some
> simple C program with it?
>
>
>> fsanitize=undefined',"-I../../../../../../rtems/5/sparc-rtems5/erc32/lib/include","-I../../../../../../rtems/5/sparc-rtems5/include/"]
>>
>> for path, subdirs, files in os.walk(directory):
>> for subdir in subdirs:
>> if(subdir=="include"):
>> includepath=os.path.join(path,subdir)
>> idx=includepath.find("..")
>> arr.append("-I../../../../"+includepath[idx+3:])
>> arr.append(file)
>> subprocess.run(arr,cwd=relativedir, stdout=subprocess.PIPE)
>> #result=subprocess.run(['./a.out'],cwd=relativedir,
>> stdout=subprocess.PIPE)
>>
>> On Thu, Apr 30, 2020 at 6:44 PM Hesham Almatary 
>> wrote:
>>
>>>
>>>
>>> On Thu, 30 Apr 2020 at 13:51, Joel Sherrill  wrote:
>>>
>>>>
>>>>
>>>> On Thu, Apr 30, 2020 at 7:34 AM suyash singh 
>>>> wrote:
>>>>
>>>>> Hello,
>>>>> I was running clang UBSan on
>>>>> bsps/sparc/erc32/btimer/btimer.c
>>>>>
>>>>> and got error
>>>>>
>>>>> /usr/bin/as: unrecognized option '-Av8'
>>>>> clang-11: error: assembler command failed with exit code 1
>>>>>
>>>>> I am not sure but is it because clang is using wrong assembler?
>>>>>
>>>>
>>>> I haven't seen anyone run into this in a long time. :)
>>>>
>>>> In this case, it is likely one of two things:
>>>>
>>>> + Look at your $PATH. Make sure the RTEMS tools are first.
>>>>
>>>> + But in your case, I expect that it is because the clang didn't
>>>> know (somehow) to put the target name in front of the as.
>>>> Did you invoke it for sparc-rtems5? If so, then there is a
>>>> path through clang where it isn't looking at the target name.
>>>>
>>> That’s likely to be the problem. I expect Suyash isn’t cross compiling
>>> with clang.
>>>
>>>
>>>> I also double checked the as manual to ensure -Av8 was in
>>>> fact a sparc option.
>>>>
>>>> --joel
>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> devel mailing list
>>>>> devel@rtems.org
>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>
>>>> ___
>>>> devel mailing list
>>>> devel@rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>> --
>>> Hesham
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>> --
> Hesham
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems assembler

2020-04-30 Thread suyash singh
I am using ubuntu 18.04 terminal

Here's the python script I wrote to find all include files and run clang
-fsanitize

# run with python3 in terminal

import subprocess
import os

relativedir="../bsps/sparc/erc32/btimer"
directory=os.path.join(os.getcwd(),"../")
file="btimer.c"
root_dir="ubsan"

arr=['clang','-target','sparc','-fsanitize=undefined',"-I../../../../../../rtems/5/sparc-rtems5/erc32/lib/include","-I../../../../../../rtems/5/sparc-rtems5/include/"]

for path, subdirs, files in os.walk(directory):
for subdir in subdirs:
if(subdir=="include"):
includepath=os.path.join(path,subdir)
idx=includepath.find("..")
arr.append("-I../../../../"+includepath[idx+3:])
arr.append(file)
subprocess.run(arr,cwd=relativedir, stdout=subprocess.PIPE)
#result=subprocess.run(['./a.out'],cwd=relativedir, stdout=subprocess.PIPE)

On Thu, Apr 30, 2020 at 6:44 PM Hesham Almatary 
wrote:

>
>
> On Thu, 30 Apr 2020 at 13:51, Joel Sherrill  wrote:
>
>>
>>
>> On Thu, Apr 30, 2020 at 7:34 AM suyash singh 
>> wrote:
>>
>>> Hello,
>>> I was running clang UBSan on
>>> bsps/sparc/erc32/btimer/btimer.c
>>>
>>> and got error
>>>
>>> /usr/bin/as: unrecognized option '-Av8'
>>> clang-11: error: assembler command failed with exit code 1
>>>
>>> I am not sure but is it because clang is using wrong assembler?
>>>
>>
>> I haven't seen anyone run into this in a long time. :)
>>
>> In this case, it is likely one of two things:
>>
>> + Look at your $PATH. Make sure the RTEMS tools are first.
>>
>> + But in your case, I expect that it is because the clang didn't
>> know (somehow) to put the target name in front of the as.
>> Did you invoke it for sparc-rtems5? If so, then there is a
>> path through clang where it isn't looking at the target name.
>>
> That’s likely to be the problem. I expect Suyash isn’t cross compiling
> with clang.
>
>
>> I also double checked the as manual to ensure -Av8 was in
>> fact a sparc option.
>>
>> --joel
>>
>>>
>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
> --
> Hesham
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

rtems assembler

2020-04-30 Thread suyash singh
Hello,
I was running clang UBSan on
bsps/sparc/erc32/btimer/btimer.c

and got error

/usr/bin/as: unrecognized option '-Av8'
clang-11: error: assembler command failed with exit code 1

I am not sure but is it because clang is using wrong assembler?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: clang static analysis of leon2

2020-04-20 Thread suyash singh
I can't find any way to group by sub directories but
I can write a script/program to make a new html file in which errors are
grouped by sub directories. I have written web scrapers with organized data
output in python and JS before.

There is a --disable-checker option and using comments to ignore parts of
file. I have not tested both techniques yet.

Some of the reports look easy to fix but the issue is that I am not usually
sure about the previous programmer's intention for writing the code that
way.

The goal of my GSOC is to
integrate the clang static analyzer in rtems
and
integrate UBSan in rtems

I would also like to improve the buildbot if needed

On Mon, Apr 20, 2020 at 11:00 PM Joel Sherrill  wrote:

> I could download the report and look through it.
>
> I assume that's the standard output from the analyzer.  For prioritization
> of looking at issues, it can be helpful if there is a way to group them by
> "area" which usually corresponds to the subdirectory. My scan showed
> one for a chain method in score/src. I think adding one line of code would
> fix that.
>
> But I also saw one in calloc.c which I think would need to be marked as
> a false report. calloc() is supposed to return a pointer so it isn't a
> leak.
> Is there a way to tell the analyzer to ignore that specific issue in that
> method?
>
> Have you looked through the reports for things that look legitimate
> and easy to fix?
>
> I'm unsure of the scope of your GSoC project so not sure other than
> to say I looked through it quickly and was able to see the issues reported
> after I unzipped the report.
>
> Is the goal to get this integrated into the RTEMS.org buildbot?
>
> --joel
>
> On Mon, Apr 20, 2020 at 12:14 PM suyash singh 
> wrote:
>
>> Find the analysis here
>> https://drive.google.com/drive/folders/1FL_euXfAtlzezDf0Vwg5-WHM22z8lbFQ
>>
>> steps here
>> https://github.com/suyashsingh234/rtems-notes
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

clang static analysis of leon2

2020-04-20 Thread suyash singh
Find the analysis here
https://drive.google.com/drive/folders/1FL_euXfAtlzezDf0Vwg5-WHM22z8lbFQ

steps here
https://github.com/suyashsingh234/rtems-notes
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

clang static analysis for at697f

2020-04-20 Thread suyash singh
Find all the reports here
https://drive.google.com/drive/folders/1FL_euXfAtlzezDf0Vwg5-WHM22z8lbFQ?usp=sharing

There is a problem in /src/rtems/bsps/shared/grlib/btimer/tlib_ckinit.c
with LEON3_IrqCtrl_Regs->timestamp[0] being undeclared
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Clang with the new build system

2020-04-10 Thread suyash singh
I came to know about the new waf build system in RTEMS. How do I start to
work on clang static analysis of BSPs with the new build system?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

UBsan working

2020-04-05 Thread suyash singh
Undefined behavior sanitizer
[image: image.png]

clang's documentation is incomplete on llvm sanitizers. Also clang installs
the ubsan files at wrong locations. There is no solution on google, so I
wrote my own

 I have written the steps for installation here

https://github.com/suyashsingh234/rtems-notes/blob/master/README.md
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Ran clang

2020-03-27 Thread suyash singh
On Fri, Mar 27, 2020 at 9:36 PM Joel Sherrill  wrote:

>
>
> On Fri, Mar 27, 2020 at 10:39 AM Gedare Bloom  wrote:
>
>> This appears to be a pretty standard llvm/clang build for a host system.
>>
>> There are two parts to consider:
>> * Using the host tools over RTEMS
>> * Using cross-compiler tools over RTEMS
>>
>> For analyzer I don't think the cross-target is a problem but I'm not
>> really sure. That should be understood before pushing further. My
>> understanding though is that most of the analyzers run on the LLVM IR, so
>> the backend is irrelevant.
>>
>
By cross compiler tools do you mean the Clang Static Analyzer should work
on all hosts after building only once?

>
> I think the RISC-V and SPARC  have BSPs that can be built with clang.
> clang/llvm has a package in the RSB. I would recommend building llvm using
> the RSB and then building the supported BSPs.
>
> That is a more solid base to use for analysis. Building RTEMS with the
> native compiler is hopeless (tilting at windmills).
>
> Also gcc 10 has improved analysis (
> https://developers.redhat.com/blog/2020/03/26/static-analysis-in-gcc-10/).
> I would like to see support for using either for static analysis.
>
> Supporting >1 open source/free tool for static analysis before fixing
> anything is important (to me). This is already built by the rtems6 RSB
> toolchain. When that builds anyway -- it tracks the tools head. :)
>
> Your project should include any additions to the RSB (if needed) and
> documenting use of the analyzers. If there is a technique to annotate
> source to avoid false positives or deliberate violations, your project
> should document that also
>

 Do you mean the RSB can already build Clang Static Analyzer and
UBSan?

 So build clang/llvm and then build BSPs for analysis?

Also gcc 10 has improved analysis (
> https://developers.redhat.com/blog/2020/03/26/static-analysis-in-gcc-10/).
> I would like to see support for using either for static analysis.
> Supporting >1 open source/free tool for static analysis before fixing
> anything is important (to me). This is already built by the rtems6 RSB
> toolchain. When that builds anyway -- it tracks the tools head. :)


 Do you mean adding both gcc 10 and clang static analyzer in RTEMS?
What is already built by rtems6 RSB toolchain?


UBSan needs code to be compiled. Will it be a problem?

Also I am quoting from clang mailing list

As of now we only analyze code that compiles without errors to begin
> with. This does force us to have some amount of interaction with the
> build system.


What are your problems with scan-build though? Is it somehow not working
> for your build system? RTEMS looks like it has a plain old Makefile; as
> long as it respects environment variables CC and CXX, "scan-build make"
> should work just fine
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Students: Submit Draft Applications

2020-03-22 Thread suyash singh
I have submitted the draft proposal and proof of enrollment

On Sat, Mar 21, 2020 at 4:20 PM Eshan Dhawan 
wrote:

> Will do it ASAP..
>
> Thanks for the heads up
> > On 21-Mar-2020, at 3:55 AM, Gedare Bloom  wrote:
> >
> > Hello Aspiring Students,
> >
> > I wanted to let you know that you can submit and revise your
> > application including your "Final" proposal as many times as you like
> > in the Official website, and that you should do so now and update it
> > periodically until the deadline. If you don't submit it then you can't
> > get picked. "Final" is not final. :)
> >
> > Gedare
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Review for gsoc proposal

2020-03-22 Thread suyash singh
I have incorporated the valuable suggestions of Dr Bloom in my proposal.
Looking forward for any further suggestions.

https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit


Thank you
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

gsoc version 8

2020-03-19 Thread suyash singh



version8March20.docx
Description: MS-Word 2007 document
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Set up the development environment

2020-03-19 Thread suyash singh
Path on computer
   -home
 -rtems-tools

Rtems tools project
https://github.com/RTEMS/rtems-tools

Personal fork of Rtems tools
https://github.com/suyashsingh234/rtems-tools

My notes
https://github.com/suyashsingh234/rtems-notes/blob/master/README.md

Gsoc proposal (draft)
https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit


On Thu, Mar 19, 2020 at 12:03 PM suyash singh 
wrote:

> ---
>  clanganalyzer/first | 1 +
>  1 file changed, 1 insertion(+)
>  create mode 100644 clanganalyzer/first
>
> diff --git a/clanganalyzer/first b/clanganalyzer/first
> new file mode 100644
> index 000..0b3ee12
> --- /dev/null
> +++ b/clanganalyzer/first
> @@ -0,0 +1 @@
> +Clang analyzer will be added here
> \ No newline at end of file
> --
> 2.17.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Set up the development environment

2020-03-19 Thread suyash singh
---
 clanganalyzer/first | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 clanganalyzer/first

diff --git a/clanganalyzer/first b/clanganalyzer/first
new file mode 100644
index 000..0b3ee12
--- /dev/null
+++ b/clanganalyzer/first
@@ -0,0 +1 @@
+Clang analyzer will be added here
\ No newline at end of file
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: What sanitizers preferred?

2020-03-17 Thread suyash singh
AddressSanitizer is supported on  Android ARM
ThreadSanitizer supported on x86_64
Memory sanitizer and UBsan not on the ones you mentioned but on freeBSD
DataFlowSanitizer is under development for x86_64 Linux

But they use virtual memory.


On Mon, Mar 16, 2020 at 10:25 PM Joel Sherrill  wrote:

>
>
> On Mon, Mar 16, 2020 at 11:05 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 15/03/2020 17:52, suyash singh wrote:
>>
>> Hello,
>> Out of
>> AddressSanitizer <http://clang.llvm.org/docs/AddressSanitizer.html>,
>> ThreadSanitizer <http://clang.llvm.org/docs/ThreadSanitizer.html>,
>> MemorySanitizer <http://clang.llvm.org/docs/MemorySanitizer.html>, and
>> DataFlowSanitizer <http://clang.llvm.org/docs/DataFlowSanitizer.html>.
>>
>> Are all of them useful as RTEMS-tools to integrate? Any other sanitizers
>> suggested?
>>
>> Asking as part of my proposed gsoc project,
>>
>> https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit?usp=sharing
>>
>> I am not sure of these sanitizers can be used in RTEMS at all. We don't
>> have virtual memory. Firstly, it would be necessary to check for each
>> sanitizer if it uses virtual memory. If yes, then is this absolutely
>> necessary or just convenient? Also the sanitizers are not available on all
>> LLVM architectures. We have to evaluate if the architectures-specific
>> adoptions can be used in RTEMS.
>>
>
> +1
>
> Another area is the compiler stack protection techniques. I have no idea
> if those are applicable to RTEMS but they would be useful if they can work.
>
> Ignoring other constraints from embedded systems, any possible technique
> to use with RTEMS must be evaluated against the constraints imposed by
> having a single address space, no VM, and single process model.
>
> You need to check if any of these will work before this project has a
> chance.
>
> I would be willing to entertain a project for an appropriate solution that
> is limited to say ARM, x86, and RISC-V.
>
> --joel
>
>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: What sanitizers preferred?

2020-03-17 Thread suyash singh
Yes it uses virtual memory. I confirmed from a LLVM sanitizer contributor.



On Mon, Mar 16, 2020 at 9:35 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 15/03/2020 17:52, suyash singh wrote:
>
> Hello,
> Out of
> AddressSanitizer <http://clang.llvm.org/docs/AddressSanitizer.html>,
> ThreadSanitizer <http://clang.llvm.org/docs/ThreadSanitizer.html>,
> MemorySanitizer <http://clang.llvm.org/docs/MemorySanitizer.html>, and
> DataFlowSanitizer <http://clang.llvm.org/docs/DataFlowSanitizer.html>.
>
> Are all of them useful as RTEMS-tools to integrate? Any other sanitizers
> suggested?
>
> Asking as part of my proposed gsoc project,
>
> https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit?usp=sharing
>
> I am not sure of these sanitizers can be used in RTEMS at all. We don't
> have virtual memory. Firstly, it would be necessary to check for each
> sanitizer if it uses virtual memory. If yes, then is this absolutely
> necessary or just convenient? Also the sanitizers are not available on all
> LLVM architectures. We have to evaluate if the architectures-specific
> adoptions can be used in RTEMS.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: What sanitizers preferred?

2020-03-17 Thread suyash singh
I have asked about the constraints on LLVM sanitizers github. Waiting for
their response.

If sanitizers is not possible, is only adding clang-analyzer too small a
project for GSOC?

If its too small there are several clang tools like thread safety analysis,
clang format and clang check which could be added. I don't know about their
usefulness in RTEMS.

On Mon, Mar 16, 2020 at 11:59 PM Gedare Bloom  wrote:

> On Mon, Mar 16, 2020 at 10:55 AM Joel Sherrill  wrote:
> >
> >
> >
> > On Mon, Mar 16, 2020 at 11:05 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >>
> >> On 15/03/2020 17:52, suyash singh wrote:
> >>
> >> Hello,
> >> Out of
> >> AddressSanitizer, ThreadSanitizer, MemorySanitizer, and
> DataFlowSanitizer.
> >>
> >> Are all of them useful as RTEMS-tools to integrate? Any other
> sanitizers suggested?
> >>
> >> Asking as part of my proposed gsoc project,
> >>
> https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit?usp=sharing
> >>
> >> I am not sure of these sanitizers can be used in RTEMS at all. We don't
> have virtual memory. Firstly, it would be necessary to check for each
> sanitizer if it uses virtual memory. If yes, then is this absolutely
> necessary or just convenient? Also the sanitizers are not available on all
> LLVM architectures. We have to evaluate if the architectures-specific
> adoptions can be used in RTEMS.
> >
> >
> > +1
> >
> > Another area is the compiler stack protection techniques. I have no idea
> if those are applicable to RTEMS but they would be useful if they can work.
> >
> > Ignoring other constraints from embedded systems, any possible technique
> to use with RTEMS must be evaluated against the constraints imposed by
> having a single address space, no VM, and single process model.
> >
> > You need to check if any of these will work before this project has a
> chance.
> >
> > I would be willing to entertain a project for an appropriate solution
> that is limited to say ARM, x86, and RISC-V.
> >
> +1
>
> UBSan is a good candidate.
>
> > --joel
> >
> >>
> >> ___
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

What sanitizers preferred?

2020-03-15 Thread suyash singh
Hello,
Out of
AddressSanitizer ,
ThreadSanitizer ,
MemorySanitizer , and
DataFlowSanitizer .

Are all of them useful as RTEMS-tools to integrate? Any other sanitizers
suggested?

Asking as part of my proposed gsoc project,
https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit?usp=sharing
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Review for my GSOC proposal: Static analysis integration

2020-03-08 Thread suyash singh
Thanks I have added now.

On Mon, Mar 9, 2020 at 11:00 AM Vaibhav Gupta 
wrote:

>
>
> On Mon, Mar 9, 2020, 10:40 AM suyash singh 
> wrote:
>
>> Please review my proposal. Thank you
>>
>> This project is inspired by https://devel.rtems.org/ticket/3710 and from
>> the mail thread with subject
>> "Improve Coverity Scan Integration: GSOC project details"
>>
>>
>> https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit?usp=sharing
>>
> Please add the link to https://devel.rtems.org/wiki/GSoC/2020.
>
> -- Vaibhav
>
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/shared/grlib/1553/b1553brm.c : addressed logic issue and unsigned_compare

2020-03-02 Thread suyash singh
Okay I will understand the programmer's intentions from now on first.

On Mon, Mar 2, 2020 at 9:10 PM Gedare Bloom  wrote:

> On Sun, Mar 1, 2020 at 11:32 AM Joel Sherrill  wrote:
> >
> >
> >
> > On Sun, Mar 1, 2020, 12:03 AM suyash singh 
> wrote:
> >>
> >> I don't know. There are checks for other things in the function when it
> return other than successful.
> >
> >
> > I don't know this code but count starts at 0. If nothing is processed, I
> would expect the count to be 0 after the loop.
> >
> > I would tend to change the <= to ==. If no data was processed, that's
> the condition. The code is just slightly off.
>
> The question is intent. This is part of grlib driver, I'm not sure
> what its interface requires from 'write', there are two cases, either
> write of 0 bytes is RTEMS_UNSUCCESSFUL or any write is RTEMS_SUCCESSFUL.
>
> I suspect a write of 0 bytes is not supposed to indicate
> RTEMS_SUCCESSFUL. So changing >= to > might be correct.
>
> >>
> >>
> >> Since it was never going to return "RTEMS_UNSATISFIED" as the "if"
> would always evaluate to true I removed the unnecessary comparison
> >>
> It is important to try to understand the programmer's intended
> behavior when dealing with these kinds of dead code issues. Maybe it
> is a bug for it to always evaluate to true? Clearly, someone thought
> at some point there would be a reason that it could be false.
>
> >> On Sat, Feb 29, 2020 at 2:52 AM Peter Dufault  wrote:
> >>>
> >>> And regardless of the value of count it is successful?
> >>>
> >>> > On Feb 28, 2020, at 12:17 , suyash singh 
> wrote:
> >>> >
> >>> > count is unsigned int and will always be >=0.
> >>> >
> >>> > On Fri, Feb 28, 2020 at 10:42 PM suyash singh <
> suyashsingh...@gmail.com> wrote:
> >>> > ---
> >>> >  bsps/shared/grlib/1553/b1553brm.c | 6 ++
> >>> >  1 file changed, 2 insertions(+), 4 deletions(-)
> >>> >
> >>> > diff --git a/bsps/shared/grlib/1553/b1553brm.c
> b/bsps/shared/grlib/1553/b1553brm.c
> >>> > index 57ef70126b..4041423541 100644
> >>> > --- a/bsps/shared/grlib/1553/b1553brm.c
> >>> > +++ b/bsps/shared/grlib/1553/b1553brm.c
> >>> > @@ -982,10 +982,8 @@ static rtems_device_driver
> brm_write(rtems_device_major_number major, rtems_devi
> >>> >
> >>> > rw_args->bytes_moved = count;
> >>> >
> >>> > -   if (count >= 0) {
> >>> > -   return RTEMS_SUCCESSFUL;
> >>> > -   }
> >>> > -   return RTEMS_UNSATISFIED;
> >>> > +   return RTEMS_SUCCESSFUL;
> >>> > +
> >>> >  }
> >>> >
> >>> >  static rtems_device_driver brm_control(rtems_device_major_number
> major, rtems_device_minor_number minor, void *arg)
> >>> > --
> >>> > 2.17.1
> >>> >
> >>> > ___
> >>> > devel mailing list
> >>> > devel@rtems.org
> >>> > http://lists.rtems.org/mailman/listinfo/devel
> >>>
> >>> Peter
> >>> -
> >>> Peter Dufault
> >>> HD Associates, Inc.  Software and System Engineering
> >>>
> >>> This email is delivered through the public internet using protocols
> subject to interception and tampering.
> >>>
> >> ___
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Improve Coverity Scan Integration: GSOC project details

2020-03-02 Thread suyash singh
Okay so I found this
https://www.synopsys.com/content/dam/synopsys/sig-assets/datasheets/coverity-misra-standards-ds-ul.pdf
and
https://github.com/ARM-software/tf-issues/issues/549
Which leads me to believe coverity provides a MISRA scanner.

Is it practical to write a program to check some of the MISRA C rules?

On Mon, Mar 2, 2020 at 12:19 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 02/03/2020 02:31, Joel Sherrill wrote:
> > *THIRD POINT-*
> > Enabling and testing MISRA rules.
> >
> >
> > Do you know of a free tool that checks Misra C rules? There are closed
> > source products that do but I don't know of a FLOSS one.
>
> cppcheck seems to have some support:
>
> http://cppcheck.sourceforge.net/misra.php
>
> My approach to MISRA rules would be to first assess which rules we want
> for the RTEMS Project. To discuss the rules, you need the MISRA C
> standard. It is not expensive, but it is also not free. Discussing MISRA
> rules an a public mailing list is also somewhat peculiar due to
> copyright issues. The relevant rules should be documented in the RTEMS
> Software Engineering manual (e.g. a nice list of numbers meaningless to
> anyone without access to the MISRA C standard). For each rule there
> should be some guideline how it can be enforced.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Improve Coverity Scan Integration: GSOC project details

2020-03-01 Thread suyash singh
This is regarding the project I would like to work in

Improve Coverity Scan Integration
https://devel.rtems.org/ticket/3710

*FIRST POINT-*
I was thinking about implementing Coverity or clang analyzer as an offline
analyzer. Would it be a suitable idea to make a separate repo just for
testing purposes?
This "testing repository" will have the updated rtems code as well the
analyzer in it. If possible this repo will be updated automatically from
the main repo.

*SECOND POINT-*
Using Travis CI for github. I have seen Travis CI checking the build of
pull requests in other repos.
Also making a special coverity branch to trigger coverity scan

*THIRD POINT-*
Enabling and testing MISRA rules.

*FOURTH POINT- *
Reducing false positives.
I have yet to figure out how to do this one.
I noticed a pattern where value overwrite errors are given for unused
values. There is email thread about it with subject "Coverity false
positive pattern"

*FIFTH POINT-*
Solving reported issues by coverity.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/shared/grlib/1553/b1553brm.c : addressed logic issue and unsigned_compare

2020-02-29 Thread suyash singh
I don't know. There are checks for other things in the function when it
return other than successful.

Since it was never going to return "RTEMS_UNSATISFIED" as the "if" would
always evaluate to true I removed the unnecessary comparison

On Sat, Feb 29, 2020 at 2:52 AM Peter Dufault  wrote:

> And regardless of the value of count it is successful?
>
> > On Feb 28, 2020, at 12:17 , suyash singh 
> wrote:
> >
> > count is unsigned int and will always be >=0.
> >
> > On Fri, Feb 28, 2020 at 10:42 PM suyash singh 
> wrote:
> > ---
> >  bsps/shared/grlib/1553/b1553brm.c | 6 ++
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/bsps/shared/grlib/1553/b1553brm.c
> b/bsps/shared/grlib/1553/b1553brm.c
> > index 57ef70126b..4041423541 100644
> > --- a/bsps/shared/grlib/1553/b1553brm.c
> > +++ b/bsps/shared/grlib/1553/b1553brm.c
> > @@ -982,10 +982,8 @@ static rtems_device_driver
> brm_write(rtems_device_major_number major, rtems_devi
> >
> > rw_args->bytes_moved = count;
> >
> > -   if (count >= 0) {
> > -   return RTEMS_SUCCESSFUL;
> > -   }
> > -   return RTEMS_UNSATISFIED;
> > +   return RTEMS_SUCCESSFUL;
> > +
> >  }
> >
> >  static rtems_device_driver brm_control(rtems_device_major_number major,
> rtems_device_minor_number minor, void *arg)
> > --
> > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
> Peter
> -
> Peter Dufault
> HD Associates, Inc.  Software and System Engineering
>
> This email is delivered through the public internet using protocols
> subject to interception and tampering.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/shared/grlib/1553/b1553brm.c : addressed logic issue and unsigned_compare

2020-02-28 Thread suyash singh
count is unsigned int and will always be >=0.

On Fri, Feb 28, 2020 at 10:42 PM suyash singh 
wrote:

> ---
>  bsps/shared/grlib/1553/b1553brm.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/bsps/shared/grlib/1553/b1553brm.c
> b/bsps/shared/grlib/1553/b1553brm.c
> index 57ef70126b..4041423541 100644
> --- a/bsps/shared/grlib/1553/b1553brm.c
> +++ b/bsps/shared/grlib/1553/b1553brm.c
> @@ -982,10 +982,8 @@ static rtems_device_driver
> brm_write(rtems_device_major_number major, rtems_devi
>
> rw_args->bytes_moved = count;
>
> -   if (count >= 0) {
> -   return RTEMS_SUCCESSFUL;
> -   }
> -   return RTEMS_UNSATISFIED;
> +   return RTEMS_SUCCESSFUL;
> +
>  }
>
>  static rtems_device_driver brm_control(rtems_device_major_number major,
> rtems_device_minor_number minor, void *arg)
> --
> 2.17.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] bsps/shared/grlib/1553/b1553brm.c : addressed logic issue and unsigned_compare

2020-02-28 Thread suyash singh
---
 bsps/shared/grlib/1553/b1553brm.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/bsps/shared/grlib/1553/b1553brm.c 
b/bsps/shared/grlib/1553/b1553brm.c
index 57ef70126b..4041423541 100644
--- a/bsps/shared/grlib/1553/b1553brm.c
+++ b/bsps/shared/grlib/1553/b1553brm.c
@@ -982,10 +982,8 @@ static rtems_device_driver 
brm_write(rtems_device_major_number major, rtems_devi
 
rw_args->bytes_moved = count; 
 
-   if (count >= 0) {
-   return RTEMS_SUCCESSFUL;
-   }
-   return RTEMS_UNSATISFIED;
+   return RTEMS_SUCCESSFUL;
+
 }
 
 static rtems_device_driver brm_control(rtems_device_major_number major, 
rtems_device_minor_number minor, void *arg)
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH] removed unneccesary assigning to rc triggering unused value error in coverity

2020-02-27 Thread suyash singh
Okay sorry I missed out on the coding standards docs.
yes code blocks edited without telling I will change its settings



On Thu, Feb 27, 2020 at 9:18 PM Gedare Bloom  wrote:

> Hi Suyash,
>
> I have a  few comments for you.
>
> First, the commit message should follow the guidance at
> https://docs.rtems.org/branches/master/eng/vc-users.html#creating-a-patch
> and follow through the link about Commit Messages. We like to have a
> short "tag" at the start of the commit to indicate the area of RTEMS
> the commit applies to, in this case, maybe "bsps/shared: ignore return
> value in display driver"  -- We don't currently have a set of standard
> tags.
>
> Second, avoid making unnecessary changes in whitespace elsewhere in
> source code. My guess is that your text editor did this for you
> automatically. You may want to investigate how to disable it from
> rewriting the entire file for formatting on open.
>
> Third, if a return value is unused, there are two options to consider:
> (a) it should be used, or (b) it should be ignored. Either way, we
> would prefer to be explicit about the programmer intent. In this case,
> does it make sense to check the return status of
> rtems_semaphore_release? Can it fail? Would it matter if it does?
>
> To explicitly ignore a return value, you can do this instead:
>
> rc = rtems_semaphore_release(...)
> (void) rc;
>
> As directed by our coding standards: "Use ‘(void) unused;’ to mark
> unused parameters and set-but-unused variables immediately after being
> set."
>
>
> On Thu, Feb 27, 2020 at 3:24 AM suyash singh 
> wrote:
> >
> > ---
> >  bsps/shared/dev/display/disp_hcms29xx.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/bsps/shared/dev/display/disp_hcms29xx.c
> b/bsps/shared/dev/display/disp_hcms29xx.c
> > index 5730b36ea9..9d3e7220cf 100644
> > --- a/bsps/shared/dev/display/disp_hcms29xx.c
> > +++ b/bsps/shared/dev/display/disp_hcms29xx.c
> > @@ -530,7 +530,7 @@ static rtems_task disp_hcms29xx_update_task
> >
> +---+
> >  | Input Parameters:
>  |
> >
> \*-*/
> > -   rtems_task_argument argument
> > +   rtems_task_argument argument
> >  )
> >
> /*-*\
> >  | Return Value:
>  |
> > @@ -597,7 +597,7 @@ static rtems_task disp_hcms29xx_update_task
> >   (int) strlen(softc_ptr->disp_param.disp_buffer);
> >}
> >if (rc == RTEMS_SUCCESSFUL) {
> > -   rc = rtems_semaphore_release(softc_ptr->disp_param.trns_sema_id);
> > +rtems_semaphore_release(softc_ptr->disp_param.trns_sema_id);
> >}
> >/*
> > * set initial offset to negative value
> > @@ -911,7 +911,7 @@ static rtems_driver_address_table disp_hcms29xx_ops
> = {
> >
> >  static disp_hcms29xx_drv_t disp_hcms29xx_drv_tbl = {
> >{/* public fields */
> > -.ops = _hcms29xx_ops,
> > +.ops = _hcms29xx_ops,
> >  .size =sizeof (disp_hcms29xx_drv_t),
> >},
> >{ /* our private fields */
> > @@ -927,6 +927,6 @@ static disp_hcms29xx_drv_t disp_hcms29xx_drv_tbl = {
> >}
> >  };
> >
> > -rtems_libi2c_drv_t *disp_hcms29xx_driver_descriptor =
> > +rtems_libi2c_drv_t *disp_hcms29xx_driver_descriptor =
> >_hcms29xx_drv_tbl.libi2c_drv_entry;
> >
> > --
> > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] removed unneccesary assigning to rc triggering unused value error in coverity

2020-02-27 Thread suyash singh
---
 bsps/shared/dev/display/disp_hcms29xx.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/bsps/shared/dev/display/disp_hcms29xx.c 
b/bsps/shared/dev/display/disp_hcms29xx.c
index 5730b36ea9..9d3e7220cf 100644
--- a/bsps/shared/dev/display/disp_hcms29xx.c
+++ b/bsps/shared/dev/display/disp_hcms29xx.c
@@ -530,7 +530,7 @@ static rtems_task disp_hcms29xx_update_task
 +---+
 | Input Parameters: |
 \*-*/
-   rtems_task_argument argument 
+   rtems_task_argument argument
 )
 /*-*\
 | Return Value: |
@@ -597,7 +597,7 @@ static rtems_task disp_hcms29xx_update_task
  (int) strlen(softc_ptr->disp_param.disp_buffer);
   }
   if (rc == RTEMS_SUCCESSFUL) {
-   rc = rtems_semaphore_release(softc_ptr->disp_param.trns_sema_id);
+rtems_semaphore_release(softc_ptr->disp_param.trns_sema_id);
   }
   /*
* set initial offset to negative value
@@ -911,7 +911,7 @@ static rtems_driver_address_table disp_hcms29xx_ops = {
 
 static disp_hcms29xx_drv_t disp_hcms29xx_drv_tbl = {
   {/* public fields */
-.ops = _hcms29xx_ops, 
+.ops = _hcms29xx_ops,
 .size =sizeof (disp_hcms29xx_drv_t),
   },
   { /* our private fields */
@@ -927,6 +927,6 @@ static disp_hcms29xx_drv_t disp_hcms29xx_drv_tbl = {
   }
 };
 
-rtems_libi2c_drv_t *disp_hcms29xx_driver_descriptor = 
+rtems_libi2c_drv_t *disp_hcms29xx_driver_descriptor =
   _hcms29xx_drv_tbl.libi2c_drv_entry;
 
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: Coverity Scan broken?

2020-02-25 Thread suyash singh
As far as I know you may need to get yourself added to the project. Sign
up/Sign in then go to https://scan.coverity.com/projects/rtems and get
yourself added. I think a button will say "add me to the project".

On Tue, Feb 25, 2020 at 9:36 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> - Am 25. Feb 2020 um 15:54 schrieb suyash singh
> suyashsingh...@gmail.com:
>
> > After clicking view defects there is a loading bar then a webpage loads.
> > Select rtems from drop down on top left.
>
> My projects list is empty.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Coverity false positive pattern

2020-02-25 Thread suyash singh
Yes it is showing for unused values

For example at line 262 in
https://scan5.coverity.com/reports.htm#v53137/p10069/fileInstanceId=164938787=45953284=1399751

On Tue, Feb 25, 2020 at 9:21 PM Joel Sherrill  wrote:

>
>
> On Tue, Feb 25, 2020 at 9:47 AM suyash singh 
> wrote:
>
>> Coverity shows value_overwrite errors for variables which are reassigned
>> new values. What should be the procedure to prevent these?
>>
>
> When I have seen these in the past, they indicate a case where a variable
> is assigned
> and assigned later without the first value being used. Is this what you
> are seeing?
>
> What file and line?
>
> We sometimes assign a variable 0 when declaring it to avoid gcc warning
> about used
> before initialized. It wouldn't surprise me if Scan didn't always like
> that.
>
> --joel
>
>
>>
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Coverity false positive pattern

2020-02-25 Thread suyash singh
Coverity shows value_overwrite errors for variables which are reassigned
new values. What should be the procedure to prevent these?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Coverity Scan broken?

2020-02-25 Thread suyash singh
After clicking view defects there is a loading bar then a webpage loads.
Select rtems from drop down on top left.

On Tue, Feb 25, 2020 at 7:49 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> the site
>
> https://scan.coverity.com/projects/rtems
>
> says the last scan was done on Jan 21, 2020. When I click on the View
> Defects page I see nothing.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Project query

2020-02-20 Thread suyash singh
All right. I will get started with coverity right away

On Fri, Feb 21, 2020 at 1:02 AM Gedare Bloom  wrote:

> On Thu, Feb 20, 2020 at 10:56 AM suyash singh 
> wrote:
> >
> > I found this interesting project
> > https://devel.rtems.org/ticket/3710
> >
> > There are no prerequisites given for this one
> >
> This one is a bit on the open-ended side. You should get started by
> looking at our current status with Coverity, and triage a few bugs.
> Convert "real bugs" from coverity scan into RTEMS tickets on Trac, or
> do analysis to identify if a coverity vulnerability is actually a
> false positive / not-a-bug. This will give you some level of
> understanding about the Coverity workflow.
>
> Beyond that, we will need to identify what, if any, patterns exist for
> false positives, and whether we need to provide a more advanced
> modeling file for Coverity. The content of our current modeling file
> is pasted below. Some of these controls are only visible to
> administrator accounts, so if the project moves forward you'd need
> that permission. We'd deal with that if necessary.
>
> There is also the possibility that clang-analyzer can be used. Jose
> recently mentioned they got it to work with some "hacks" -- a good
> project could be to make it working in a productive manner for our
> open-source ecosystem.
>
> I could see the two (coverity and clang-analyzer) being a good basis
> for a GSoC that focuses on integration of static analysis tools in
> RTEMS "devops"
>
> Modeling file for RTEMS
> ---
> //
> // RTEMS-tools currently does not have anything to model for Coverity.
> // Having a file makes them happy we have a fully configured project. :)
> //
>
> typedef unsigned int uint32_t;
>
> void rtems_fatal_error_occurred(uint32_t the_error)
> {
>   __coverity_panic__();
> }
>
> #define rtems_interrupt_disable( _level ) \
>   do { \
> _level = 0; \
>   } while(0)
>
> ---
>
> Gedare
>
> > On Thu, Feb 20, 2020 at 10:31 PM Gedare Bloom  wrote:
> >>
> >> On Thu, Feb 20, 2020 at 9:43 AM suyash singh 
> wrote:
> >> >
> >> > So can I work on x86_64 BSP without hardware with simulator?
> >> > https://devel.rtems.org/ticket/2898
> >> >
> >> > Also out of the prerequisites I only know C programming language but
> I am ready to learn everything else.
> >> >
> >> I think it will be too hard to work on a new BSP/port without the
> >> assembly programming language experience in that architecture.
> >>
> >> I'd suggest you look for projects for which you possess all/most of
> >> the prerequisites (when explicitly stated).
> >>
> >> Gedare
> >>
> >> > On Thu, Feb 20, 2020 at 9:13 AM Gedare Bloom 
> wrote:
> >> >>
> >> >> On Wed, Feb 19, 2020 at 6:29 PM Joel Sherrill 
> wrote:
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Wed, Feb 19, 2020, 6:12 PM John Millard 
> wrote:
> >> >> >>
> >> >> >> Greetings:
> >> >> >>
> >> >> >> I took Joel’s week-long class in June.
> >> >> >
> >> >> >
> >> >> > :) Thanks. Hope you enjoyed it.
> >> >> >
> >> >> >> I’m currently retired and looking for a project, but clearly not
> a GSoC guy. The default list of tickets is mostly old or currently assigned.
> >> >> >
> >> >> >
> >> >> > Currently assigned may not mean as much as you think. It is often
> done by someone to direct the ticket to who wrote the code. I know I often
> file tickets where I have looked into who is most likely to fix it and
> assign it to them.
> >> >> >
> >> >> > For example, I need to file a ticket for breakages building
> rtems-examples using waf. And when you build RTEMS using rtems6 tools,
> there are breakages because rtems5 is not replaced with rtems6 is still in
> some places. I reported both I think this week to devel.
> >> >> >
> >> >> >> The “open projects” page looks more relevant. I can buy hardware
> if somewhat reasonably priced. Having actual hardware would be somewhat
> preferred, even if qemu is amazing. I can do assembly (most familiar with
> Intel, but open to learning), low-level C down to the hardware, and have
> experience with OS level programming and drivers, serial and network

Re: Project query

2020-02-20 Thread suyash singh
I found this interesting project
https://devel.rtems.org/ticket/3710

There are no prerequisites given for this one

On Thu, Feb 20, 2020 at 10:31 PM Gedare Bloom  wrote:

> On Thu, Feb 20, 2020 at 9:43 AM suyash singh 
> wrote:
> >
> > So can I work on x86_64 BSP without hardware with simulator?
> > https://devel.rtems.org/ticket/2898
> >
> > Also out of the prerequisites I only know C programming language but I
> am ready to learn everything else.
> >
> I think it will be too hard to work on a new BSP/port without the
> assembly programming language experience in that architecture.
>
> I'd suggest you look for projects for which you possess all/most of
> the prerequisites (when explicitly stated).
>
> Gedare
>
> > On Thu, Feb 20, 2020 at 9:13 AM Gedare Bloom  wrote:
> >>
> >> On Wed, Feb 19, 2020 at 6:29 PM Joel Sherrill  wrote:
> >> >
> >> >
> >> >
> >> > On Wed, Feb 19, 2020, 6:12 PM John Millard 
> wrote:
> >> >>
> >> >> Greetings:
> >> >>
> >> >> I took Joel’s week-long class in June.
> >> >
> >> >
> >> > :) Thanks. Hope you enjoyed it.
> >> >
> >> >> I’m currently retired and looking for a project, but clearly not a
> GSoC guy. The default list of tickets is mostly old or currently assigned.
> >> >
> >> >
> >> > Currently assigned may not mean as much as you think. It is often
> done by someone to direct the ticket to who wrote the code. I know I often
> file tickets where I have looked into who is most likely to fix it and
> assign it to them.
> >> >
> >> > For example, I need to file a ticket for breakages building
> rtems-examples using waf. And when you build RTEMS using rtems6 tools,
> there are breakages because rtems5 is not replaced with rtems6 is still in
> some places. I reported both I think this week to devel.
> >> >
> >> >> The “open projects” page looks more relevant. I can buy hardware if
> somewhat reasonably priced. Having actual hardware would be somewhat
> preferred, even if qemu is amazing. I can do assembly (most familiar with
> Intel, but open to learning), low-level C down to the hardware, and have
> experience with OS level programming and drivers, serial and network
> transport, debuggers.
> >> >
> >> >
> >> > If that's the direction you want to go in, the x86_64 port and bsp
> are incomplete. There should be plenty of room to get things working. This
> would help ween us off of depending on legacy boot PCs.
> >> >
> >> +1
> >>
> >> And so far few students to work on it, and it is a big area to work on.
> >>
> >> There is also an open project to improve legacy x86:
> >> https://devel.rtems.org/ticket/2900
> >>
> >> >>
> >> >> Is there some priority on the projects? They are all equal, but some
> are more equal than others. I can guess the scope on some of them.
> >> >
> >> >
> >> > For the most part, there isn't much priority. If you ask different
> people, you will likely get different answers.
> >> >
> >> >>
> >> >> Suggestions welcome.
> >> >>
> >> >> John
> >> >> —where there are tools, a will, and a will to build tools there is a
> way
> >> >>
> >> >> _
> >> >>
> >> >> devel mailing list
> >> >> devel@rtems.org
> >> >> http://lists.rtems.org/mailman/listinfo/devel
> >> >>
> >> >>
> >> >> ___
> >> >> devel mailing list
> >> >> devel@rtems.org
> >> >> http://lists.rtems.org/mailman/listinfo/devel
> >> >
> >> > ___
> >> > devel mailing list
> >> > devel@rtems.org
> >> > http://lists.rtems.org/mailman/listinfo/devel
> >> ___
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Project query

2020-02-20 Thread suyash singh
So can I work on x86_64 BSP without hardware with simulator?
https://devel.rtems.org/ticket/2898

Also out of the prerequisites I only know C programming language but I am
ready to learn everything else.

On Thu, Feb 20, 2020 at 9:13 AM Gedare Bloom  wrote:

> On Wed, Feb 19, 2020 at 6:29 PM Joel Sherrill  wrote:
> >
> >
> >
> > On Wed, Feb 19, 2020, 6:12 PM John Millard  wrote:
> >>
> >> Greetings:
> >>
> >> I took Joel’s week-long class in June.
> >
> >
> > :) Thanks. Hope you enjoyed it.
> >
> >> I’m currently retired and looking for a project, but clearly not a GSoC
> guy. The default list of tickets is mostly old or currently assigned.
> >
> >
> > Currently assigned may not mean as much as you think. It is often done
> by someone to direct the ticket to who wrote the code. I know I often file
> tickets where I have looked into who is most likely to fix it and assign it
> to them.
> >
> > For example, I need to file a ticket for breakages building
> rtems-examples using waf. And when you build RTEMS using rtems6 tools,
> there are breakages because rtems5 is not replaced with rtems6 is still in
> some places. I reported both I think this week to devel.
> >
> >> The “open projects” page looks more relevant. I can buy hardware if
> somewhat reasonably priced. Having actual hardware would be somewhat
> preferred, even if qemu is amazing. I can do assembly (most familiar with
> Intel, but open to learning), low-level C down to the hardware, and have
> experience with OS level programming and drivers, serial and network
> transport, debuggers.
> >
> >
> > If that's the direction you want to go in, the x86_64 port and bsp are
> incomplete. There should be plenty of room to get things working. This
> would help ween us off of depending on legacy boot PCs.
> >
> +1
>
> And so far few students to work on it, and it is a big area to work on.
>
> There is also an open project to improve legacy x86:
> https://devel.rtems.org/ticket/2900
>
> >>
> >> Is there some priority on the projects? They are all equal, but some
> are more equal than others. I can guess the scope on some of them.
> >
> >
> > For the most part, there isn't much priority. If you ask different
> people, you will likely get different answers.
> >
> >>
> >> Suggestions welcome.
> >>
> >> John
> >> —where there are tools, a will, and a will to build tools there is a way
> >>
> >> _
> >>
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
> >>
> >>
> >> ___
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Project query

2020-02-19 Thread suyash singh
sorry clicked reply instead of "reply all"


I don't have any boards and experience. What interests me about this
project is that microblaze is used in FPGA which are used in a variety of
fields like science, medicine and defence. Porting an os to it would be a
great contribution

On Tue, Feb 18, 2020 at 9:30 PM Gedare Bloom  wrote:

> Hello Suyash,
>
> On Tue, Feb 18, 2020 at 8:07 AM suyash singh 
> wrote:
> >
> > Hello,
> >
> > I am interested in "Port RTEMS to MicroBlaze"
> > https://devel.rtems.org/ticket/2902
> >
> > How do I start understanding the previous work done and understanding
> what else needs to be done?
> >
> Hopefully Hesham or Joel will chime in on their effort.
>
> Do you have one or more Xilinx FPGA boards that you can use? Do you
> have any experience with Microblaze? If not, what interests you about
> this project?
>
> Gedare
>
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Project query

2020-02-18 Thread suyash singh
Hello,

I am interested in "Port RTEMS to MicroBlaze"
https://devel.rtems.org/ticket/2902

How do I start understanding the previous work done and understanding what
else needs to be done?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] first commit

2020-02-14 Thread suyash singh
Hello I am Suyash Singh and this is my first commit. I am from India and
currently in 2nd year of BTech Computer Science Engineering. I am hoping to
participate in RTEMS as a GSOC student and beyond.



On Sat, Feb 15, 2020 at 12:56 PM suyash singh 
wrote:

> ---
>  testsuites/samples/hello/init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/testsuites/samples/hello/init.c
> b/testsuites/samples/hello/init.c
> index 34ded37c55..7f165d17a5 100644
> --- a/testsuites/samples/hello/init.c
> +++ b/testsuites/samples/hello/init.c
> @@ -22,7 +22,7 @@ static rtems_task Init(
>  {
>rtems_print_printer_fprintf_putc(_test_printer);
>TEST_BEGIN();
> -  printf( "Hello World\n" );
> +  printf( "Hello RTEMS. I am Suyash Singh" );
>TEST_END();
>rtems_test_exit( 0 );
>  }
> --
> 2.17.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] first commit

2020-02-14 Thread suyash singh
---
 testsuites/samples/hello/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c
index 34ded37c55..7f165d17a5 100644
--- a/testsuites/samples/hello/init.c
+++ b/testsuites/samples/hello/init.c
@@ -22,7 +22,7 @@ static rtems_task Init(
 {
   rtems_print_printer_fprintf_putc(_test_printer);
   TEST_BEGIN();
-  printf( "Hello World\n" );
+  printf( "Hello RTEMS. I am Suyash Singh" );
   TEST_END();
   rtems_test_exit( 0 );
 }
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel