Re: RSB fails to build qemu.bset

[Cláudio Maia]

On 04/05/20 00:29, Chris Johns wrote:
> On 3/5/20 4:33 am, Joel Sherrill wrote:
>>
>> On Sat, May 2, 2020, 12:42 PM Cláudio Maia > > wrote:
>>
>> Hello everyone,
>>
>> I'm trying to build the toolchain for the build set devel/qemu.bset
>> with the goal of executing RTEMS applications on top of LEON3 bsp on
>> QEMU.
>> Unfortunately, when I build the toolchain using:

>> If this is a recent Linux distribution, try the qemu4 bset.
>>
>> The qemu.bset is for an older version of qemu which seems to have build 
>> issues on newer hosts.
> I do not recall why we have both? Is there a need?
>
>> Qemu5 was also recently released.
>>
>> I suspect we need to renamed this to have a major number on the end. 
>> That might encourage picking a newer release.
> Do we need the major version number on the end? Why do we have it there?
>
>> FWIW qemu4 builds on Centos 7 which means newer qemu on older Linux 
>> works where older qemu on newer Linux doesn't.
> What hosts build qemu4?

I'm using Ubuntu 18.04.4 LTS with kernel version 4.15.0-99-generic 64-bit 
version. 

>
> chris

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

Re: [PATCH rtems_waf] rtems: Add uninstall option to the list of commands

[Vijay Kumar Banerjee]

On Mon, May 4, 2020 at 4:39 AM Chris Johns  wrote:

> Hi
>
> Are uninstall command useful with RTEMS? A use case that shows how it
> would be used may help.
>
> The use case in mind was libbsd. The uninstall command comes handy in
cleaning off the files that were installed, and there's no need to delete it
manually. I remember having some issues with libbsd while taking a trial
and error approach in searching for the right sources, the residue of the
old build would often cause problems and I had to delete them manually.

> I use separate prefixes to manage this. We do not track common files
> when installing to a common prefix so building ARM and then PowerPC to
> the same prefix then uninstalling only the PowerPC build would remove
> files needed by ARM.
>
> waf only removes the files that have been installed with install_files. If
I
run ./waf uninstall from libbsd, only the files under
arm-rtems5/beagleboneblack/lib
are getting affected.

> Chris
>
> On 4/5/20 5:04 am, Vijay Kumar Banerjee wrote:
> > ---
> >   rtems.py | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/rtems.py b/rtems.py
> > index ceabcd9..067a213 100644
> > --- a/rtems.py
> > +++ b/rtems.py
> > @@ -131,7 +131,7 @@ def init(ctx, filters = None, version = None,
> long_commands = False, bsp_init =
> >   #
> >   commands = []
> >   for cmd in waflib.Options.commands:
> > -if cmd in ['build', 'clean', 'install']:
> > +if cmd in ['build', 'clean', 'install', 'uninstall']:
> >   for x in arch_bsps:
> >   commands += [cmd + '-' + x]
> >   else:
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[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: clang sparc: generated .o file incompatible with elf64-x86-64

[Joel Sherrill]

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.

--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: clang sparc: generated .o file incompatible with elf64-x86-64

[Hesham Almatary]

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

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

[Hesham Almatary]

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

Re: Different build time warnings for ticket 3908

[Richi Dubey]

Got it.

>> The "pre-installed gcc" shouldn't come into play here, because you are
>> using an RTEMS cross-compiler, e.g., sparc5-rtems-gcc.

I was unsure of this as recently I had seen a mail in the devel list
saying that someone had an error because of changes in the latest
gcc/clang version. I cannot find that mail again.

Thanks for the reply.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS Tester questions and issues

[Cláudio Maia]

Hello everyone,

I have a few questions and a few issues concerning RTEMS Tester which I would 
like to clarify with you.
Starting by the questions, these are the following:

- Is it possible to use RTEMS Tester to connect directly to a target board and 
run tests (similar to what is shown in the figure of 
https://docs.rtems.org/branches/master/user/testing/gdb-jtag.html)?
If so, can someone please show me how or provide me with the pages in the 
documentation where I can find this info.

- Somehow related to the above, let's assume that I want to access a remote SIS 
target and send some tests to this "remote instance", is it possible to achieve 
this scenario with RTEMS Tester?

- Moreover, in the above page it is mentioned that it is possible for RTEMS 
Tester to invoke the architecture target GDB and specify a GDB script that will 
be executed on the target. Again, I don't find information on the documentation 
or by looking at the list of arguments provided by the Tester. Could someone 
provide me with a reference or show me how to achieve this?


Now concerning the issues. I have noticed that running the RTEMS Tester using 
the following BSPs has issues, as follows:

-  "--rtems-bsp=leon3-qemu"

When using this BSP the following command line is used: "qemu-system-sparc 
-no-reboot -nographic -serial null -serial mon:stdio -M leon3_generic -kernel 
hello.exe" which invokes QEMU monitor and causes the test to be invalid.
However, if we remove "-serial null" the tests execute as expected.

From "qemu.cfg", I've noticed that "-serial null -serial mon:stdio" is set if 
we do not use coverage:

%if %{defined coverage}
 %define qemu_use_serial_console
%endif

...

%if %{defined qemu_use_serial_console}
 %define qemu_opts_serial -monitor none -serial stdio
%else
 %define qemu_opts_serial -serial null -serial mon:stdio
%endif

Is this the expected behaviour?


- "--rtems-bsp=leon3-run"

This BSP invokes sparc-rtems5-run, e.g. "sparc-rtems5-run -a -leon3 
sparc-rtems5/c/leon3/testsuites/samples/hello.exe", which is not being 
generated anymore as it was discussed here:

https://lists.rtems.org/pipermail/devel/2020-February/057760.html
https://lists.rtems.org/pipermail/devel/2020-March/057906.html

and was the cause for removing "erc32-run.ini", as described here 
https://lists.rtems.org/pipermail/devel/2020-March/058563.html.

Can "leon3-run.ini" which is invoking "sparc-rtems5-run" be removed? Generally, 
can we assume that anything related to "sparc-rtems5-run" can be removed?

Regards,
Cláudio

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

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

[suyash singh]

>
> 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/x86_64-linux-gnu/7/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib -L/lib/x86_64-linux-gnu
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/7/../../.. /tmp/test1-6da71f.o --push-state
--no-as-needed -lubsan --pop-state -lgcc --push-state --as-needed -lgcc_s
--pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state
/usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o
ld.lld: error: /tmp/test1-6da71f.o is incompatible with elf64-x86-64
collect2: error: ld returned 1 exit 

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

[suyash singh]

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
-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/x86_64-linux-gnu/7/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib -L/lib/x86_64-linux-gnu
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/7/../../.. /tmp/test1-ffe267.o --push-state
--no-as-needed -lubsan --pop-state -lgcc --push-state --as-needed -lgcc_s
--pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state
/usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o
ld.lld: error: /tmp/test1-ffe267.o is incompatible with elf64-x86-64
collect2: error: ld returned 1 exit stat

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

[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
> -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-l

25th Birthday of Oldest Commit in Repository

[Joel Sherrill]

Hi

May 4 1995 was the day I took the last snapshot of the RTEMS source code
from the Army research project and imported it into a public CVS
repository. There had been snapshots and releases for years prior to that.
But this was a huge transition as OAR put in place what evolved into the
RTEMS.org infrastructure.  More details at
https://www.rtems.org/node/132 including
a link to the commit and some statistics.

There have been many contributors since then.  It is a tribute to all of
the users and contributors that RTEMS is so vibrant after 30 years.

Happy birthday!!

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

Gsoc improvement for next time

[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

m2005 untar error on msys2 (tar01 directory)

[Joel Sherrill]

Hi

Windows (msys2) is completely dead in the water for m2005 due to a symlink
added to the RTEMS source

$ tar Jxf rtems-5.0.0-m2005-1.tar.xz
tar: rtems-5.0.0-m2005-1/testsuites/libtests/tar01/symlink: Cannot create
symlink to ‘home/test_file’: No such file or directory
tar: Exiting with failure status due to previous errors

The rtems tar file has this in it:

-rw-r--r-- chris/1010 1228 2020-05-01 03:03
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/tar01.scn
lrwxr-xr-x chris/10100 2020-05-01 03:03
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/symlink -> home/test_file
-rw-r--r-- chris/1010 8108 2020-05-01 03:03
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/init.c
-rw-r--r-- chris/1010  478 2020-05-01 03:03
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/tar01.doc
drwxr-xr-x chris/10100 2020-05-01 03:03
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/home/
-rw-r--r-- chris/1010   73 2020-05-01 03:03
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/home/test_file

We recently battled this with newlib and that solution won't work here.

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

Re: m2005 untar error on msys2 (tar01 directory)

[Chris Johns]

On 5/5/20 10:46 am, Joel Sherrill wrote:

Hi

Windows (msys2) is completely dead in the water for m2005 due to a 
symlink added to the RTEMS source


$ tar Jxf rtems-5.0.0-m2005-1.tar.xz
tar: rtems-5.0.0-m2005-1/testsuites/libtests/tar01/symlink: Cannot 
create symlink to ‘home/test_file’: No such file or directory

tar: Exiting with failure status due to previous errors

The rtems tar file has this in it:

-rw-r--r-- chris/1010     1228 2020-05-01 03:03 
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/tar01.scn
lrwxr-xr-x chris/1010        0 2020-05-01 03:03 
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/symlink -> home/test_file
-rw-r--r-- chris/1010     8108 2020-05-01 03:03 
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/init.c
-rw-r--r-- chris/1010      478 2020-05-01 03:03 
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/tar01.doc
drwxr-xr-x chris/1010        0 2020-05-01 03:03 
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/home/
-rw-r--r-- chris/1010       73 2020-05-01 03:03 
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/home/test_file


We recently battled this with newlib and that solution won't work here.


I have raised #3938 and will remove the link from the source tree. The 
test will need to be fixed at some point.


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

Re: [PATCH rtems_waf] rtems: Add uninstall option to the list of commands

[Chris Johns]

On 4/5/20 8:16 pm, Vijay Kumar Banerjee wrote:



On Mon, May 4, 2020 at 4:39 AM Chris Johns > wrote:


Hi

Are uninstall command useful with RTEMS? A use case that shows how it
would be used may help.

The use case in mind was libbsd. The uninstall command comes handy in
cleaning off the files that were installed, and there's no need to delete it
manually. I remember having some issues with libbsd while taking a trial
and error approach in searching for the right sources, the residue of the
old build would often cause problems and I had to delete them manually.


I understand. I see this as a development issue and not something a user 
would typically do. A release can have the pieces in a vertically 
software stack built on top of each other, i.e. a single prefix. For 
development where you can have specific pieces that are moving relative 
to each other I recommend separate sandboxing. The user manual details 
this. Prefix based sandboxing lets you remove a specific prefix without 
needing to rebuild the whole stack.



I use separate prefixes to manage this. We do not track common files
when installing to a common prefix so building ARM and then PowerPC to
the same prefix then uninstalling only the PowerPC build would remove
files needed by ARM.

waf only removes the files that have been installed with install_files. If I
run ./waf uninstall from libbsd, only the files under 
arm-rtems5/beagleboneblack/lib

are getting affected.


That must be the default uninstall for waf. We should decide to move one 
way or the other, that is remove the uninstall because it is broken or 
we fix it, i.e. your patch?


I hesitate adding something that is not manually tested often and so not 
kept up to date. Would a unit test be a solution? Something that 
collects a hash based stamp for all the files under a prefix, performs 
the install and the uninstall steps and then verifies the prefix tree is 
exactly the same?


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

[PATCH 6/7] libdl/rap: Correctly check the return enum from rela calls

[chrisj]

From: Chris Johns 

- The change from bool to an enum did not trip a compiler warning
  and only the rel path was changed. The rela path was missed so
  archs like SPARC failed.

Updates #3969
---
 cpukit/libdl/rtl-rap.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/cpukit/libdl/rtl-rap.c b/cpukit/libdl/rtl-rap.c
index 4e4540c156..32f4bd6ff5 100644
--- a/cpukit/libdl/rtl-rap.c
+++ b/cpukit/libdl/rtl-rap.c
@@ -326,6 +326,7 @@ rtems_rtl_rap_relocate (rtems_rtl_rap* rap, rtems_rtl_obj* 
obj)
 if (!symsect)
 {
   free (symname_buffer);
+  rtems_rtl_set_error (EINVAL, "symsect not found: %d", info >> 8);
   return false;
 }
 
@@ -389,8 +390,12 @@ rtems_rtl_rap_relocate (rtems_rtl_rap* rap, rtems_rtl_obj* 
obj)
   r, (int) type, offset, (int) addend,
   symname, (uintmax_t) symtype, (uintmax_t) symvalue);
 
-if (!rtems_rtl_elf_relocate_rela (obj, &rela, targetsect,
-  symname, symtype, symvalue))
+if (rtems_rtl_elf_relocate_rela (obj,
+ &rela,
+ targetsect,
+ symname,
+ symtype,
+ symvalue) == 
rtems_rtl_elf_rel_failure)
 {
   free (symname_buffer);
   return false;
@@ -409,8 +414,12 @@ rtems_rtl_rap_relocate (rtems_rtl_rap* rap, rtems_rtl_obj* 
obj)
   r, (int) type, offset,
   symname, (uintmax_t) symtype, (uintmax_t) symvalue);
 
-if (rtems_rtl_elf_relocate_rel (obj, &rel, targetsect,
- symname, symtype, symvalue) == 
rtems_rtl_elf_rel_failure)
+if (rtems_rtl_elf_relocate_rel (obj,
+&rel,
+targetsect,
+symname,
+symtype,
+symvalue) == rtems_rtl_elf_rel_failure)
 {
   free (symname_buffer);
   return false;
-- 
2.24.1

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

[PATCH 2/7] libdl/sparc: Print trace message of reloc failture path

[chrisj]

From: Chris Johns 

Updates #3969
---
 cpukit/libdl/rtl-mdreloc-sparc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/cpukit/libdl/rtl-mdreloc-sparc.c b/cpukit/libdl/rtl-mdreloc-sparc.c
index 548c24132b..f8a4312a8a 100644
--- a/cpukit/libdl/rtl-mdreloc-sparc.c
+++ b/cpukit/libdl/rtl-mdreloc-sparc.c
@@ -232,8 +232,11 @@ rtems_rtl_elf_relocate_rela (rtems_rtl_obj*obj,
* We use the fact that relocation types are an `enum'
* Note: R_SPARC_6 is currently numerically largest.
*/
-  if (type > R_TYPE(6))
+  if (type > R_TYPE(TLS_TPOFF64)) {
+if (rtems_rtl_trace (RTEMS_RTL_TRACE_RELOC))
+  printf("rtl: invalid reloc type: %d\n", (int) type);
 return rtems_rtl_elf_rel_failure;
+  }
 
   value = rela->r_addend;
 
-- 
2.24.1

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

[PATCH 5/7] libdl/obj-comp: Add trace prints when decompressing

[chrisj]

From: Chris Johns 

Updates #3969
---
 cpukit/include/rtems/rtl/rtl-trace.h |  2 ++
 cpukit/libdl/rtl-obj-comp.c  | 31 
 2 files changed, 33 insertions(+)

diff --git a/cpukit/include/rtems/rtl/rtl-trace.h 
b/cpukit/include/rtems/rtl/rtl-trace.h
index 06c72c8992..196b4ff42e 100644
--- a/cpukit/include/rtems/rtl/rtl-trace.h
+++ b/cpukit/include/rtems/rtl/rtl-trace.h
@@ -54,7 +54,9 @@ typedef uint32_t rtems_rtl_trace_mask;
 #define RTEMS_RTL_TRACE_ARCHIVE_SYMS   (1UL << 13)
 #define RTEMS_RTL_TRACE_DEPENDENCY (1UL << 14)
 #define RTEMS_RTL_TRACE_BIT_ALLOC  (1UL << 15)
+#define RTEMS_RTL_TRACE_COMP   (1UL << 16)
 #define RTEMS_RTL_TRACE_ALL(0xUL & 
~(RTEMS_RTL_TRACE_CACHE | \
+ 
RTEMS_RTL_TRACE_COMP | \
  
RTEMS_RTL_TRACE_GLOBAL_SYM | \
  
RTEMS_RTL_TRACE_ARCHIVE_SYMS))
 
diff --git a/cpukit/libdl/rtl-obj-comp.c b/cpukit/libdl/rtl-obj-comp.c
index 36825baebe..4608a41bf4 100644
--- a/cpukit/libdl/rtl-obj-comp.c
+++ b/cpukit/libdl/rtl-obj-comp.c
@@ -21,10 +21,13 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
 #include "rtl-error.h"
+#include 
 
 #include "fastlz.h"
 
@@ -91,6 +94,13 @@ rtems_rtl_obj_comp_read (rtems_rtl_obj_comp* comp,
 return false;
   }
 
+  if (rtems_rtl_trace (RTEMS_RTL_TRACE_COMP))
+printf ("rtl:  comp: %2d: fd=%d length=%zu level=%u offset=%" PRIdoff_t " 
area=[%"
+PRIdoff_t ",%" PRIdoff_t "] read=%" PRIu32 " size=%zu\n",
+comp->fd, comp->cache->fd, length, comp->level, comp->offset,
+comp->offset, comp->offset + length,
+comp->read, comp->size);
+
   if (comp->fd != comp->cache->fd)
   {
 comp->level = 0;
@@ -104,10 +114,18 @@ rtems_rtl_obj_comp_read (rtems_rtl_obj_comp* comp,
 
 if (buffer_level)
 {
+  if (rtems_rtl_trace (RTEMS_RTL_TRACE_COMP))
+printf ("rtl:  comp: copy: length=%zu\n",
+buffer_level);
+
   memcpy (bin, comp->buffer, buffer_level);
 
   if ((comp->level - buffer_level) != 0)
   {
+if (rtems_rtl_trace (RTEMS_RTL_TRACE_COMP))
+  printf ("rtl:  comp: copy-down: level=%u length=%zu\n",
+  comp->level, comp->level - buffer_level);
+
 memmove (comp->buffer,
  comp->buffer + buffer_level,
  comp->level - buffer_level);
@@ -126,6 +144,10 @@ rtems_rtl_obj_comp_read (rtems_rtl_obj_comp* comp,
   size_t   in_length = sizeof (block_size);
   int  decompressed;
 
+  if (rtems_rtl_trace (RTEMS_RTL_TRACE_COMP))
+printf ("rtl:  comp: read block-size: offset=%" PRIdoff_t "\n",
+comp->offset);
+
   if (!rtems_rtl_obj_cache_read (comp->cache, comp->fd, comp->offset,
  (void**) &input, &in_length))
 return false;
@@ -136,6 +158,10 @@ rtems_rtl_obj_comp_read (rtems_rtl_obj_comp* comp,
 
   in_length = block_size;
 
+  if (rtems_rtl_trace (RTEMS_RTL_TRACE_COMP))
+printf ("rtl:  comp: read block: offset=%" PRIdoff_t " size=%u\n",
+comp->offset, block_size);
+
   if (!rtems_rtl_obj_cache_read (comp->cache, comp->fd, comp->offset,
  (void**) &input, &in_length))
 return false;
@@ -172,6 +198,11 @@ rtems_rtl_obj_comp_read (rtems_rtl_obj_comp* comp,
   comp->offset += block_size;
 
   comp->level = decompressed;
+
+  if (rtems_rtl_trace (RTEMS_RTL_TRACE_COMP))
+printf ("rtl:  comp: expand: offset=%" PRIdoff_t \
+" level=%u read=%" PRIu32 "\n",
+comp->offset, comp->level, comp->read);
 }
   }
 
-- 
2.24.1

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

[PATCH 4/7] libdl/obj-cache: Fail if the read offset is past the file length

[chrisj]

From: Chris Johns 

- The check was for greater than and not equal or greater

Updates #3969
---
 cpukit/libdl/rtl-obj-cache.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/cpukit/libdl/rtl-obj-cache.c b/cpukit/libdl/rtl-obj-cache.c
index 28d3b02a16..8791e2b1d5 100644
--- a/cpukit/libdl/rtl-obj-cache.c
+++ b/cpukit/libdl/rtl-obj-cache.c
@@ -80,7 +80,7 @@ rtems_rtl_obj_cache_read (rtems_rtl_obj_cache* cache,
   struct stat sb;
 
   if (rtems_rtl_trace (RTEMS_RTL_TRACE_CACHE))
-printf ("rtl: cache: %2d: fd=%d offset=%" PRIdoff_t "length=%zu area=[%"
+printf ("rtl: cache: %2d: fd=%d offset=%" PRIdoff_t " length=%zu area=[%"
 PRIdoff_t ",%" PRIdoff_t "] cache=[%" PRIdoff_t ",%" PRIdoff_t "] 
size=%zu\n",
 fd, cache->fd, offset, *length,
 offset, offset + *length,
@@ -95,7 +95,7 @@ rtems_rtl_obj_cache_read (rtems_rtl_obj_cache* cache,
 
   if (cache->fd == fd)
   {
-if (offset > cache->file_size)
+if (offset >= cache->file_size)
 {
   rtems_rtl_set_error (EINVAL, "offset past end of file: offset=%i 
size=%i",
(int) offset, (int) cache->file_size);
@@ -110,6 +110,7 @@ rtems_rtl_obj_cache_read (rtems_rtl_obj_cache* cache,
   *length = cache->file_size - offset;
   if (rtems_rtl_trace (RTEMS_RTL_TRACE_CACHE))
 printf ("rtl: cache: %2d: truncate length=%d\n", fd, (int) *length);
+
 }
   }
 
@@ -175,8 +176,8 @@ rtems_rtl_obj_cache_read (rtems_rtl_obj_cache* cache,
 }
 
 if (rtems_rtl_trace (RTEMS_RTL_TRACE_CACHE))
-  printf ("rtl: cache: %2d: seek: offset=%" PRIdoff_t "buffer_offset=%zu"
-  "read=%zu cache=[%" PRIdoff_t ",%" PRIdoff_t "] "
+  printf ("rtl: cache: %2d: seek: offset=%" PRIdoff_t " buffer_offset=%zu"
+  " read=%zu cache=[%" PRIdoff_t ",%" PRIdoff_t "] "
   "dist=%" PRIdoff_t "\n",
   fd, offset + buffer_offset, buffer_offset, buffer_read,
   offset, offset + buffer_read,
-- 
2.24.1

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

[PATCH 1/7] libdl: Fix comment.

[chrisj]

From: Chris Johns 

Updates #3969
---
 cpukit/libdl/rtl-elf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/libdl/rtl-elf.c b/cpukit/libdl/rtl-elf.c
index 9370f36989..75b3d9c953 100644
--- a/cpukit/libdl/rtl-elf.c
+++ b/cpukit/libdl/rtl-elf.c
@@ -1717,7 +1717,7 @@ rtems_rtl_elf_file_load (rtems_rtl_obj* obj, int fd)
* 1. See if there are any common variables and if there are add a
*common section.
* 2. Add up the common.
-   * 3.
+   * 3. The load the symbols.
*/
   if (!rtems_rtl_obj_load_symbols (obj, fd, rtems_rtl_elf_common, &common))
 return false;
-- 
2.24.1

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

[PATCH 3/7] libdl/obj: Fix RAP format call table.

[chrisj]

From: Chris Johns 

Updates #3969
---
 cpukit/libdl/rtl-obj.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/cpukit/libdl/rtl-obj.c b/cpukit/libdl/rtl-obj.c
index 0c4a624c18..a7dd740549 100644
--- a/cpukit/libdl/rtl-obj.c
+++ b/cpukit/libdl/rtl-obj.c
@@ -60,7 +60,6 @@ static const rtems_rtl_loader_table 
loaders[RTEMS_RTL_LOADERS] =
   { .check = rtems_rtl_rap_file_check,
 .load  = rtems_rtl_rap_file_load,
 .unload= rtems_rtl_rap_file_unload,
-.unload= rtems_rtl_rap_file_unload,
 .signature = rtems_rtl_rap_file_sig },
 #endif
 #if RTEMS_RTL_ELF_LOADER
-- 
2.24.1

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

[PATCH 7/7] testsuite/dl06: Add a local define to control tracing

[chrisj]

From: Chris Johns 

Closes #3969
---
 testsuites/libtests/dl06/dl-load.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/testsuites/libtests/dl06/dl-load.c 
b/testsuites/libtests/dl06/dl-load.c
index d78e9d1ef8..211c05cd3c 100644
--- a/testsuites/libtests/dl06/dl-load.c
+++ b/testsuites/libtests/dl06/dl-load.c
@@ -6,6 +6,8 @@
  * http://www.rtems.org/license/LICENSE.
  */
 
+#define DL06_DEBUG_TRACING 0
+
 #include 
 
 #include 
-- 
2.24.1

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

Re: m2005 untar error on msys2 (tar01 directory)

[Sebastian Huber]

On 05/05/2020 06:11, Chris Johns wrote:


On 5/5/20 10:46 am, Joel Sherrill wrote:

Hi

Windows (msys2) is completely dead in the water for m2005 due to a 
symlink added to the RTEMS source


$ tar Jxf rtems-5.0.0-m2005-1.tar.xz
tar: rtems-5.0.0-m2005-1/testsuites/libtests/tar01/symlink: Cannot 
create symlink to ‘home/test_file’: No such file or directory

tar: Exiting with failure status due to previous errors

The rtems tar file has this in it:

-rw-r--r-- chris/1010     1228 2020-05-01 03:03 
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/tar01.scn
lrwxr-xr-x chris/1010        0 2020-05-01 03:03 
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/symlink -> home/test_file
-rw-r--r-- chris/1010     8108 2020-05-01 03:03 
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/init.c
-rw-r--r-- chris/1010      478 2020-05-01 03:03 
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/tar01.doc
drwxr-xr-x chris/1010        0 2020-05-01 03:03 
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/home/
-rw-r--r-- chris/1010       73 2020-05-01 03:03 
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/home/test_file


We recently battled this with newlib and that solution won't work here.


I have raised #3938 and will remove the link from the source tree. The 
test will need to be fixed at some point.



I can confirm this issue. I tried a workaround you find on the internet:

$ export MSYS=winsymlinks:nativestrict

$ tar xf rtems-5.0.0-m2005-1.tar.xz
tar: rtems-5.0.0-m2005-1/testsuites/libtests/tar01/symlink: Cannot 
create symlink to ‘home/test_file’: Operation not permitted

tar: Exiting with failure status due to previous errors

It seems I have a problem with symbolic links in general:

$ ln -s a b
ln: failed to create symbolic link 'b': Operation not permitted

If I unset MSYS, then the ln -s copies the file.

$ unset MSYS

$ ln -s a b

$ echo x > a

$ echo y > b

$ cat a
x

$ cat b
y

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

Re: m2005 untar error on msys2 (tar01 directory)

[Sebastian Huber]

On 05/05/2020 07:08, Sebastian Huber wrote:


On 05/05/2020 06:11, Chris Johns wrote:


On 5/5/20 10:46 am, Joel Sherrill wrote:

Hi

Windows (msys2) is completely dead in the water for m2005 due to a 
symlink added to the RTEMS source


$ tar Jxf rtems-5.0.0-m2005-1.tar.xz
tar: rtems-5.0.0-m2005-1/testsuites/libtests/tar01/symlink: Cannot 
create symlink to ‘home/test_file’: No such file or directory

tar: Exiting with failure status due to previous errors

The rtems tar file has this in it:

-rw-r--r-- chris/1010     1228 2020-05-01 03:03 
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/tar01.scn
lrwxr-xr-x chris/1010        0 2020-05-01 03:03 
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/symlink -> home/test_file
-rw-r--r-- chris/1010     8108 2020-05-01 03:03 
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/init.c
-rw-r--r-- chris/1010      478 2020-05-01 03:03 
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/tar01.doc
drwxr-xr-x chris/1010        0 2020-05-01 03:03 
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/home/
-rw-r--r-- chris/1010       73 2020-05-01 03:03 
rtems-5.0.0-m2005-1/testsuites/libtests/tar01/home/test_file


We recently battled this with newlib and that solution won't work here.


I have raised #3938 and will remove the link from the source tree. 
The test will need to be fixed at some point.



I can confirm this issue. I tried a workaround you find on the internet:

$ export MSYS=winsymlinks:nativestrict

$ tar xf rtems-5.0.0-m2005-1.tar.xz
tar: rtems-5.0.0-m2005-1/testsuites/libtests/tar01/symlink: Cannot 
create symlink to ‘home/test_file’: Operation not permitted

tar: Exiting with failure status due to previous errors

It seems I have a problem with symbolic links in general:

$ ln -s a b
ln: failed to create symbolic link 'b': Operation not permitted

If I unset MSYS, then the ln -s copies the file.

$ unset MSYS

$ ln -s a b

$ echo x > a

$ echo y > b

$ cat a
x

$ cat b
y

I tried to build the tools to check if the test runs. I got this in a 
mingw64 shell:


config: tools/rtems-gdb-9.1-1.cfg
error: shell macro failed: sh -c 
"/c/test-msys64/home/release/rsb/source-builder/sb/rtems-build-dep -c 
x86_64-w64-mingw32-gcc  -I '-IC:/test-msys64/mingw64/include/python3.8 
-IC:/test-msys64/mingw64/include/python3.8
-IC:/test-msys64/mingw64/include/python3.8 
-IC:/test-msys64/mingw64/include/python3.8' -H Python.h": 1: sh: -c: 
line 0: unexpected EOF while looking for matching `''

sh: -c: line 1: syntax error: unexpected end of file

In a msys2 shell I get:

$ ../source-builder/sb-set-builder --prefix=/opt/rtems/5 5/rtems-sparc
error: no hosts defaults found; please add

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

Re: m2005 untar error on msys2 (tar01 directory)

[Chris Johns]

On 5/5/20 3:08 pm, Sebastian Huber wrote:

On 05/05/2020 06:11, Chris Johns wrote:
It seems I have a problem with symbolic links in general:


Yes. There are other ways we can handle this rather than banging heads 
against it. Thanks for taking closer look.


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

Re: m2005 untar error on msys2 (tar01 directory)

[Chris Johns]

On 5/5/20 3:20 pm, Sebastian Huber wrote:

In a msys2 shell I get:

$ ../source-builder/sb-set-builder --prefix=/opt/rtems/5 5/rtems-sparc
error: no hosts defaults found; please add



What does `python source-builder/sb/windows.py` show?

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

Re: m2005 untar error on msys2 (tar01 directory)

[Sebastian Huber]

On 05/05/2020 07:20, Sebastian Huber wrote:

I tried to build the tools to check if the test runs. I got this in a 
mingw64 shell:


config: tools/rtems-gdb-9.1-1.cfg
error: shell macro failed: sh -c 
"/c/test-msys64/home/release/rsb/source-builder/sb/rtems-build-dep -c 
x86_64-w64-mingw32-gcc  -I '-IC:/test-msys64/mingw64/include/python3.8 
-IC:/test-msys64/mingw64/include/python3.8
-IC:/test-msys64/mingw64/include/python3.8 
-IC:/test-msys64/mingw64/include/python3.8' -H Python.h": 1: sh: -c: 
line 0: unexpected EOF while looking for matching `''
sh: -c: line 1: syntax error: unexpected end of file 


If I run the command by hand, it seems to work:

$ sh -c 
"/c/test-msys64/home/release/rsb/source-builder/sb/rtems-build-dep -c 
x86_64-w64-mingw32-gcc  -I '-IC:/test-msys64/mingw64/include/python3.8 
-IC:/test-msys64/mingw64/include/python3.8 
-IC:/test-msys64/mingw64/include/python3.8 
-IC:/test-msys64/mingw64/include/python3.8' -H Python.h"

found

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

Re: m2005 untar error on msys2 (tar01 directory)

[Sebastian Huber]

On 05/05/2020 07:22, Chris Johns wrote:


On 5/5/20 3:20 pm, Sebastian Huber wrote:

In a msys2 shell I get:

$ ../source-builder/sb-set-builder --prefix=/opt/rtems/5 5/rtems-sparc
error: no hosts defaults found; please add



What does `python source-builder/sb/windows.py` show?

$ python source-builder/sb/windows.py
Traceback (most recent call last):
  File "source-builder/sb/windows.py", line 192, in 
    pprint.pprint(load())
  File "source-builder/sb/windows.py", line 64, in load
    raise error.general('invalid POSIX python for Windows')
error.general: error: invalid POSIX python for Windows
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: m2005 untar error on msys2 (tar01 directory)

[Chris Johns]

On 5/5/20 3:34 pm, Sebastian Huber wrote:

On 05/05/2020 07:22, Chris Johns wrote:


On 5/5/20 3:20 pm, Sebastian Huber wrote:

In a msys2 shell I get:

$ ../source-builder/sb-set-builder --prefix=/opt/rtems/5 5/rtems-sparc
error: no hosts defaults found; please add



What does `python source-builder/sb/windows.py` show?

$ python source-builder/sb/windows.py
Traceback (most recent call last):
   File "source-builder/sb/windows.py", line 192, in 
     pprint.pprint(load())
   File "source-builder/sb/windows.py", line 64, in load
     raise error.general('invalid POSIX python for Windows')
error.general: error: invalid POSIX python for Windows


What does `os.uname()` return?

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

Re: m2005 untar error on msys2 (tar01 directory)

[Sebastian Huber]

On 05/05/2020 07:41, Chris Johns wrote:


On 5/5/20 3:34 pm, Sebastian Huber wrote:

On 05/05/2020 07:22, Chris Johns wrote:


On 5/5/20 3:20 pm, Sebastian Huber wrote:

In a msys2 shell I get:

$ ../source-builder/sb-set-builder --prefix=/opt/rtems/5 5/rtems-sparc
error: no hosts defaults found; please add



What does `python source-builder/sb/windows.py` show?

$ python source-builder/sb/windows.py
Traceback (most recent call last):
   File "source-builder/sb/windows.py", line 192, in 
 pprint.pprint(load())
   File "source-builder/sb/windows.py", line 64, in load
 raise error.general('invalid POSIX python for Windows')
error.general: error: invalid POSIX python for Windows


What does `os.uname()` return?


In the msys shell:

$ python
Python 3.7.4 (default, Jul 11 2019, 09:35:14)
[GCC 9.1.0] on msys
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.uname()
posix.uname_result(sysname='MSYS_NT-6.1-7601', nodename='Blub', 
release='3.0.7-338.x86_64', version='2019-07-11 10:58 UTC', 
machine='x86_64')


In the mingw64 shell:

$ python
Python 3.8.2 (default, Feb 27 2020, 05:27:33)  [GCC 9.2.0 64 bit 
(AMD64)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.uname()
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: module 'os' has no attribute 'uname'

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

Re: m2005 untar error on msys2 (tar01 directory)

[Chris Johns]

On 5/5/20 3:44 pm, Sebastian Huber wrote:

On 05/05/2020 07:41, Chris Johns wrote:


On 5/5/20 3:34 pm, Sebastian Huber wrote:

On 05/05/2020 07:22, Chris Johns wrote:


On 5/5/20 3:20 pm, Sebastian Huber wrote:

In a msys2 shell I get:

$ ../source-builder/sb-set-builder --prefix=/opt/rtems/5 5/rtems-sparc
error: no hosts defaults found; please add


What does `python source-builder/sb/windows.py` show?

$ python source-builder/sb/windows.py
Traceback (most recent call last):
   File "source-builder/sb/windows.py", line 192, in 
 pprint.pprint(load())
   File "source-builder/sb/windows.py", line 64, in load
 raise error.general('invalid POSIX python for Windows')
error.general: error: invalid POSIX python for Windows


What does `os.uname()` return?


In the msys shell:

$ python
Python 3.7.4 (default, Jul 11 2019, 09:35:14)


That is what I have installed.


[GCC 9.1.0] on msys
Type "help", "copyright", "credits" or "license" for more information.
 >>> import os
 >>> os.uname()
posix.uname_result(sysname='MSYS_NT-6.1-7601', nodename='Blub', 
release='3.0.7-338.x86_64', version='2019-07-11 10:58 UTC', 
machine='x86_64')


I have ...

>>> os.uname()
posix.uname_result(sysname='MINGW64_NT-10.0-18362', nodename='weng', 
release='3.0.7-338.x86_64', version='2019-07-11 10:58 UTC', 
machine='x86_64')


I have never seen `MSYS_NT` before.

I am running Window-10 on real hardware running Version 1903, OS build 
18362.778. I have not picked up the feature update yet. I am remote to 
the machine and do not want to try.



In the mingw64 shell:

$ python
Python 3.8.2 (default, Feb 27 2020, 05:27:33)  [GCC 9.2.0 64 bit 
(AMD64)] on win32


This is wrong python, the os.name() check is only done on POSIX builds 
of python.



Type "help", "copyright", "credits" or "license" for more information.
 >>> import os
 >>> os.uname()
Traceback (most recent call last):
   File "", line 1, in 
AttributeError: module 'os' has no attribute 'uname'



Correct, it is not a posix build.

Using the m2005-1 snapshot I ran `windows.py` from same `msys` python 
without error ...


$ python source-builder/sb/windows.py
{'___setup_shell': ('exe', 'required', '%{__sh}'),
 '__bash': ('exe', 'required', 'bash'),
 '__bison': ('exe', 'required', 'bison'),
 '__bzip2': ('exe', 'required', 'bzip2'),
 '__cat': ('exe', 'required', 'cat'),
 '__cc': ('exe', 'required', 'x86_64-w64-mingw32-gcc'),
 '__chgrp': ('exe', 'required', 'chgrp'),
 '__chmod': ('exe', 'required', 'chmod'),
[snip]
 '_usr': ('dir', 'optional', '/opt/local'),
 '_var': ('dir', 'optional', '/opt/local/var'),
 '_windows_os': ('none', 'none', 'mingw32'),
 'gdb_python2': '/c/msys64/mingw64/bin/python2.exe',
 'gdb_python3': '/c/msys64/mingw64/bin/python3.exe'}

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

Re: m2005 untar error on msys2 (tar01 directory)

[Sebastian Huber]

On 05/05/2020 08:01, Chris Johns wrote:



What does `os.uname()` return?


In the msys shell:

$ python
Python 3.7.4 (default, Jul 11 2019, 09:35:14)


That is what I have installed.


[GCC 9.1.0] on msys
Type "help", "copyright", "credits" or "license" for more information.
 >>> import os
 >>> os.uname()
posix.uname_result(sysname='MSYS_NT-6.1-7601', nodename='Blub', 
release='3.0.7-338.x86_64', version='2019-07-11 10:58 UTC', 
machine='x86_64')


I have ...

>>> os.uname()
posix.uname_result(sysname='MINGW64_NT-10.0-18362', nodename='weng', 
release='3.0.7-338.x86_64', version='2019-07-11 10:58 UTC', 
machine='x86_64')


I have never seen `MSYS_NT` before.

I am running Window-10 on real hardware running Version 1903, OS build 
18362.778. I have not picked up the feature update yet. I am remote to 
the machine and do not want to try. 
I did the testing on a more or less retired Windows 7 VM. I will setup a 
Windows 10 VM.

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

Re: m2005 untar error on msys2 (tar01 directory)

[Chris Johns]

On 5/5/20 4:05 pm, Sebastian Huber wrote:

On 05/05/2020 08:01, Chris Johns wrote:



What does `os.uname()` return?


In the msys shell:

$ python
Python 3.7.4 (default, Jul 11 2019, 09:35:14)


That is what I have installed.


[GCC 9.1.0] on msys
Type "help", "copyright", "credits" or "license" for more information.
 >>> import os
 >>> os.uname()
posix.uname_result(sysname='MSYS_NT-6.1-7601', nodename='Blub', 
release='3.0.7-338.x86_64', version='2019-07-11 10:58 UTC', 
machine='x86_64')


I have ...

>>> os.uname()
posix.uname_result(sysname='MINGW64_NT-10.0-18362', nodename='weng', 
release='3.0.7-338.x86_64', version='2019-07-11 10:58 UTC', 
machine='x86_64')


I have never seen `MSYS_NT` before.

I am running Window-10 on real hardware running Version 1903, OS build 
18362.778. I have not picked up the feature update yet. I am remote to 
the machine and do not want to try. 
I did the testing on a more or less retired Windows 7 VM. I will setup a 
Windows 10 VM.


Oh OK, maybe keep it? Could you patch the RSB and see if it works?

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