Re: Reg. Assistance in development of code for OS
Hello, My OS project has a very long history (I started with it in 1988) and it is running on 1000s of installations. Thus, it's a pretty mature project. Doing something meaningful on the kernel side requires a lot of knowledge of how it operates, and I'm afraid there is no more documentation than what is on my homepage (http://www.rdos.net/rdos), and you would need to read the source code for the rest. Also, most of the kernel code is in x86 assembler using segmentation. Still, I could of course give you advice on things. Note that this is not an academic project, rather started as a hobby project and now is part of commercial software. It's not Posix or Unix-like, nor Windows-like, rather was designed from scratch. The only project idea I currently have is to move the file system drivers to a new operational model which I discussed here: https://forum.osdev.org/viewtopic.php?f=15&t=40928 Regards, Leif Ekblad --- On 2021-03-04 07:02, Suhan Gautam via Gcc wrote: Dear Sir, I am persuing B. Tech. in Computer Science from a reputed College in Delhi NCR. I have domain knowledge of software languages like Java, Python, PHP, C ++, C. In addition I Am adept in DBase related softwares like Oracle. I would request your kind self to provide me an opportunity to iro coding in OS softwares. This will definitely help me in developing my skills in this niche field. Thanking you, With best regards, Suhan Gautam.
Re: Reg. Assistance in development of code for OS
On Thu, Mar 4, 2021 at 3:00 AM wrote: > Hello, > > My OS project has a very long history (I started with it in 1988) and it > is running on 1000s of installations. Thus, it's a pretty mature > project. Doing something meaningful on the kernel side requires a lot of > knowledge of how it operates, and I'm afraid there is no more > documentation than what is on my homepage (http://www.rdos.net/rdos), > and you would need to read the source code for the rest. Also, most of > the kernel code is in x86 assembler using segmentation. Still, I could > of course give you advice on things. Note that this is not an academic > project, rather started as a hobby project and now is part of commercial > software. It's not Posix or Unix-like, nor Windows-like, rather was > designed from scratch. > > The only project idea I currently have is to move the file system > drivers to a new operational model which I discussed here: > https://forum.osdev.org/viewtopic.php?f=15&t=40928 This is the wrong forum for this but I don't want to discourage anyone from contributing to a FLOSS project. :) RTEMS.org is a real-time OS of similar age as RDOS. Our origin is also 1988. We support almost 20 target architectures and ~200 BSPs. RTEMS is a single address space, multi-threaded RTOS and has a significant amount of POSIX support. We have multiple filesystems, networking, SMP, etc. We have regularly participated in Google Summer of Code and keep an active list of open projects and smaller tasks. We keep these as tickets and this page provides a list of them. We are also open to other ideas: https://devel.rtems.org/wiki/Developer/OpenProjects Like RDOS, it is harder to find work on the core itself but there are lots of other areas to contribute. In fairness, there are lots of free OS projects out there, each with a different mission and targeted set of users. Find one that interests you. Those that have participated in student programs like GSoC are going to tend to have open projects pages. --joel RTEMS > > Regards, > Leif Ekblad > > --- > > > On 2021-03-04 07:02, Suhan Gautam via Gcc wrote: > > Dear Sir, > > I am persuing B. Tech. in Computer Science from a reputed College in > > Delhi > > NCR. I have domain knowledge of software languages like Java, Python, > > PHP, > > C ++, C. In addition I Am adept in DBase related softwares like Oracle. > > I > > would request your kind self to provide me an opportunity to iro coding > > in > > OS softwares. This will definitely help me in developing my skills in > > this > > niche field. > > > > Thanking you, > > > > With best regards, > > > > Suhan Gautam. >
Re: HELP: MIPS PC Relative Addressing
On Thu, 4 Mar 2021, Jiaxun Yang wrote: > > I'm not sure though why you try to avoid composed relocations given we've > > had them for 20+ years now. Relocations are just calculation operators > > for expressions evaluated at link time rather than assembly or high-level > > language compilation time. And just like we don't invent single operators > > for complex combinations of `+', `&', `%', `<<', etc. and instead compose > > the exiting ones in expressions used in various programming languages to > > get the desired calculation, we don't need to do that for relocation and > > we can just have a collection of simple relocation operators to choose > > from and combine. > > Well just because binutils code drives me crazy:-( > I tired very hard to understand those stuff but when I trying to modify them > I just got endless assert failure or other unreasonable errors :-/ The code certainly has decades of baggage, it can be complicated and even hairy at places. I guess nobody knows it all or understands all parts right away. However you'll get better with getting around it as you work with it longer and get experience, you just need patience. Nobody says learning tough stuff is easy. But difficulty with understanding one particular implementation mustn't drive psABI design decisions! Maciej
A weird bug
Guys,
I've been trying to debug a linker error (which I thought was a bug in
my optimization.) Well it turns out it occurs in a brand new virgin
version of the compiler running with binutils 2.36 which is the latest
version. I'm posting this on both the binutils list and gcc list
because people of either list are just as likely to have an idea about
what's going on. Note, I tried to walk though the ld code in gdb but
it's nontrivial trying figure out why an error occured. I can't just
set a watch point on a flag because, at least in some places it seems
like the default state of the flag is failure and the code then
proceeds to try various things to see if they'll work.
Regarding the compiler that I built:
$ git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
Now here is how I built it:
./my_dual_build_script gcc_virgin_build 2>build_log_virgin 1>&2
where my_dual_build_script is:
cd $1
BASE=`pwd`
echo BASE = $BASE
touch BU_objdir objdir install
rm -rf BU_objdir objdir install
mkdir BU_objdir objdir install
cd BU_objdir
echo BUILDING BINUTILS IN `pwd`
../binutils-2.36/configure --prefix=$BASE/install
make CFLAGS='-O2 -g' CXXFLAGS='-O2 -g' -j 12
##make CFLAGS='-O0 -g' CXXFLAGS='-O2 -g' -j 12
make install
cd ../objdir
echo BUILDING GCC IN `pwd`
../sources/configure --prefix=$BASE/install --disable-bootstrap
-enable-language=c,c++,lto --disable-multilib --enable-valgrind-annotations
##make CFLAGS='-O0 -g' CXXFLAGS='-O0 -g' -j 12
make CFLAGS='-O2 -g' CXXFLAGS='-O2 -g' -j 12
make install
My installed gcc is:
$ gcc -v
Using built-in specs.
COLLECT_GCC=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)
My istalled binutils are:
$ ld -v
GNU ld (GNU Binutils for Ubuntu) 2.30
Now the application that failing during testing is 505.x264_5 which is
from SPEC17. Note, please don't try to duplicate this bug unless you
have access to SPEC17 and are running an identical system because
Martin Liska tried to do this on a different system but but he
couldn't get it to duplicate.
Now for any SPEC heads out there here's the germane parts
from its confige file.
define gcc_dir/home/gary/gcc_virgin_build/install
preENV_LD_LIBRARY_PATH = %{gcc_dir}/lib64/:%{gcc_dir}/lib/:/lib64
SPECLANG= %{gcc_dir}/bin/
CC = $(SPECLANG)gcc --verbose -std=c99 %{model}
CXX = $(SPECLANG)g++ -std=c++03 %{model}
FC = $(SPECLANG)gfortran %{model}
OPTIMIZE = -O2 -v -Wl,--verbose=1 -Wl,-debug
COPTIMIZE = -save-temps
Finally here linker's part of the x264 build output:
/home/gary/gcc_virgin_build/install/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../x86_64-pc-linux-gnu/bin/ld
-plugin
/home/gary/gcc_virgin_build/install/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/liblto_plugin.so
-plugin-opt=/home/gary/gcc_virgin_build/install/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
-plugin-opt=-fresolution=ldecod_r.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
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o
ldecod_r /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o
/home/gary/gcc_virgin_build/install/lib/gcc/x86_64-pc-linux-gnu/11.0.1/crtbegin.o
-L/home/gary/gcc_virgin_build/install/lib/gcc/x86_64-pc-linux-gnu/11.0.1
-L/home/gary/gcc_virgin_build/install/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../lib64
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/home/gary/gcc_virgin_build/install/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../x86_64-p
gcc-8-20210304 is now available
Snapshot gcc-8-20210304 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20210304/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 revision 1ea62bb7364ed733a74540e273ff2060e0c3e522 You'll find: gcc-8-20210304.tar.xzComplete GCC SHA256=5ee8b5aa7ec54957fe8575f691a7c95a4e08f6e7a0fc9a7908cac5084b31431f SHA1=a1cb83a8ffbd48216b4663354e5c054a2dca6177 Diffs from 8-20210225 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: A weird bug
On Thu, Mar 4, 2021 at 3:18 PM Gary Oblock via Gcc wrote: > > Guys, > > I've been trying to debug a linker error (which I thought was a bug in > my optimization.) Well it turns out it occurs in a brand new virgin > version of the compiler running with binutils 2.36 which is the latest > version. I'm posting this on both the binutils list and gcc list > because people of either list are just as likely to have an idea about > what's going on. Note, I tried to walk though the ld code in gdb but > it's nontrivial trying figure out why an error occured. I can't just > set a watch point on a flag because, at least in some places it seems > like the default state of the flag is failure and the code then > proceeds to try various things to see if they'll work. > > Regarding the compiler that I built: Here are scripts I used to build Linux/x86-64 GCC toolchain: https://gitlab.com/hjl.tools/x86-64-linux-toolchain -- H.J.
Re: A weird bug
On Thu, Mar 4, 2021 at 3:19 PM Gary Oblock via Gcc wrote:
>
> Guys,
>
> I've been trying to debug a linker error (which I thought was a bug in
> my optimization.) Well it turns out it occurs in a brand new virgin
> version of the compiler running with binutils 2.36 which is the latest
> version. I'm posting this on both the binutils list and gcc list
> because people of either list are just as likely to have an idea about
> what's going on. Note, I tried to walk though the ld code in gdb but
> it's nontrivial trying figure out why an error occured. I can't just
> set a watch point on a flag because, at least in some places it seems
> like the default state of the flag is failure and the code then
> proceeds to try various things to see if they'll work.
I will give you a hint, pre GCC 10, defaulted to -fcommon, GCC 10+
defaults to -fno-common.
Thanks,
Andrew
>
> Regarding the compiler that I built:
>
> $ git status
> On branch master
> Your branch is up to date with 'origin/master'.
>
> nothing to commit, working tree clean
>
> Now here is how I built it:
>
> ./my_dual_build_script gcc_virgin_build 2>build_log_virgin 1>&2
>
> where my_dual_build_script is:
>
> cd $1
> BASE=`pwd`
> echo BASE = $BASE
> touch BU_objdir objdir install
> rm -rf BU_objdir objdir install
> mkdir BU_objdir objdir install
>
> cd BU_objdir
> echo BUILDING BINUTILS IN `pwd`
> ../binutils-2.36/configure --prefix=$BASE/install
> make CFLAGS='-O2 -g' CXXFLAGS='-O2 -g' -j 12
> ##make CFLAGS='-O0 -g' CXXFLAGS='-O2 -g' -j 12
> make install
>
> cd ../objdir
> echo BUILDING GCC IN `pwd`
> ../sources/configure --prefix=$BASE/install --disable-bootstrap
> -enable-language=c,c++,lto --disable-multilib --enable-valgrind-annotations
> ##make CFLAGS='-O0 -g' CXXFLAGS='-O0 -g' -j 12
> make CFLAGS='-O2 -g' CXXFLAGS='-O2 -g' -j 12
> make install
>
> My installed gcc is:
>
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=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)
>
> My istalled binutils are:
>
> $ ld -v
> GNU ld (GNU Binutils for Ubuntu) 2.30
>
> Now the application that failing during testing is 505.x264_5 which is
> from SPEC17. Note, please don't try to duplicate this bug unless you
> have access to SPEC17 and are running an identical system because
> Martin Liska tried to do this on a different system but but he
> couldn't get it to duplicate.
>
> Now for any SPEC heads out there here's the germane parts
> from its confige file.
>
>define gcc_dir/home/gary/gcc_virgin_build/install
>
>preENV_LD_LIBRARY_PATH = %{gcc_dir}/lib64/:%{gcc_dir}/lib/:/lib64
>SPECLANG= %{gcc_dir}/bin/
>CC = $(SPECLANG)gcc --verbose -std=c99 %{model}
>CXX = $(SPECLANG)g++ -std=c++03 %{model}
>FC = $(SPECLANG)gfortran %{model}
>
>OPTIMIZE = -O2 -v -Wl,--verbose=1 -Wl,-debug
>COPTIMIZE = -save-temps
>
> Finally here linker's part of the x264 build output:
>
> /home/gary/gcc_virgin_build/install/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../x86_64-pc-linux-gnu/bin/ld
> -plugin
> /home/gary/gcc_virgin_build/install/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/liblto_plugin.so
>
> -plugin-opt=/home/gary/gcc_virgin_build/install/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
> -plugin-opt=-fresolution=ldecod_r.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
> --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o
> ldecod_r /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o
> /home/gary/gcc_virgin_build/in
