I'm currently studying the xv6 OS.
I found out here how to add a system call by modifying the MAKEFILE file.
My question is: how do we add simple text files or any other kind of file to be seen in the xv6 system once it boots?
README file in Xv6 is a generic file too. Searching for occurrences of README in the MakeFile and adding your required file will be sufficient.
Suppose new.txt is the file you want to add.
Parts of the MakeFile to be changed are:
1)
fs.img: mkfs README new.txt $(UPROGS)
./mkfs fs.img README new.txt $(UPROGS)
2)
PRINT = runoff.list runoff.spec README new.txt toc.hdr toc.ftr $(FILES)
3)
EXTRA=\
mkfs.c ulib.c user.h cat.c echo.c forktest.c grep.c kill.c\
ln.c ls.c mkdir.c rm.c stressfs.c usertests.c wc.c zombie.c\
printf.c umalloc.c\
README new.txt dot-bochsrc *.pl toc.* runoff runoff1 runoff.list\
.gdbinit.tmpl gdbutil\
Like Sravani suggested, I added my "new.txt" adjecent to all occurences of README. I got the error:
make: No rule to make target `sample.txt', needed by `fs.img'. Stop.
Then I removed the file type, i.e ".txt". Works well now!
Related
I'm messing around with xv6 in QEMU, and I made a new file in the directory I'm in, and when I'm in QEMU and type ls the file isn't listed. In fact, lots of files aren't listed, and I can't figure out why it lists the ones it does. It seems to only list compiled .c files, and for some reason a README, but not the compiled .c file I just made.
Possibly because you forgot to add your .c file in the Makefile. Suppose test.c is the file you want to add. You need to add it in the Makefile under UPROGS as:
UPROGS=\
....
....
_test\
and under EXTRA as:
EXTRA=\
mkfs.c ulib.c user.h cat.c echo.c forktest.c grep.c kill.c\
ln.c ls.c mkdir.c rm.c stressfs.c usertests.c wc.c zombie.c\
printf.c umalloc.c **test.c**\
README new.txt dot-bochsrc *.pl toc.* runoff runoff1 runoff.list\
.gdbinit.tmpl gdbutil\
If you want to add generic files like README to Xv6, refer to this question:
Add a generic file in xv6 makefile
I need to perform some test coverage with gcov on a shared library I am working on.
The problem is libtool renames the object files from my-name.c to libmylib_la-my-name.lo and gcov is unable to handle that conversion. Everytime I run it, the error cannot open notes file is generated.
If I manually rename my-name.c to libmylib_la-my-name.c after the build gcov works fine, so there is no other problem apart the filename mangling.
Addendum
Trying to provide a minimal working example I discovered the filename mangling happens only when lib..._la_CFLAGS is set (and also when it is set to an empty value).
cat <<EOT > configure.ac
AC_INIT(sample,0.0.1)
AC_CONFIG_SRCDIR(configure.ac)
AM_INIT_AUTOMAKE(foreign)
LT_INIT
AC_PROG_CC
AC_CONFIG_FILES(Makefile)
AC_OUTPUT
EOT
cat <<EOT > Makefile.am
lib_LTLIBRARIES=libsample.la
libsample_la_SOURCES=sample.c
# The following line triggers the filename mangling (libsample_la-sample.lo instead of sample.lo)
libsample_la_CFLAGS=
EOT
touch sample.c && autoreconf -if && ./configure && make
Is there a way to avoid the filename mangling operated by libtool or to let gcov understand the filename mangling scheme?
Gcov gcda and gcno files are named after object files. You can run gcov from source directory directly on object file or you can use -o option of gcov to specify the object file and corresponding gcov files.
For example I have a small project that builds a shared library. I pass gcov flags to make command:
make CFLAGS="-O0 --coverage" LDFLAGS=--coverage
Object files and corresponding gcno files are created in src/.libs folder:
$ ls -la src/.libs
libtest_la-test.o
libtest_la-test.gcno
The source file is in src folder
$ ls src/
test.c
Next I run my test suite and gcda files are created:
$ ls -la src/.libs
libtest_la-test.o
libtest_la-test.gcno
libtest_la-test.gcda
Now I can enter src directory and run gcov, specifiying object file name:
$ gcov -o .libs/libtest_la-test.o test.c
File ‘test.c’
Lines executed:27.08% of 96
Creating ‘test.c.gcov'
It is also possible to just run gcov on object file:
$ gcov .libs/libtest_la-test.o
File ’test.c’
Lines executed:27.08% of 96
Creating ’test.c.gcov'
Or even just specifying base name of object file and gcov files:
$ gcov .libs/libtest_la-test
File ’test.c’
Lines executed:27.08% of 96
Creating ’test.c.gcov'
But I would suggest another automated approach that works very well for me, using lcov. I invoke it from top directory specifying paths to source files and object files:
$ lcov --base-directory src --directory src/.libs/ --capture --output-file gcov.info
Capturing coverage data from src/.libs/
Found gcov version: 4.8.2
Scanning src/.libs/ for .gcda files ...
Found 10 data files in src/.libs/
Processing .libs/test_la-test.gcda
[…]
Finished .info-file creation
$ genhtml -o html/coverage gcov.info
Reading data file gcov.info
Found 10 entries.
Found common filename prefix "/usr/src/libtest”
Writing .css and .png files.
Generating output.
Processing file src/test.c
[…]
Writing directory view page.
Overall coverage rate:
lines......: 56.1% (2098 of 3737 lines)
functions..: 68.8% (139 of 202 functions)
Now html/coverage directory contains html files that can be easily analyzed in a web browser.
Libtool shouldn't change .c file names. However, it does change .o file names; this is because it needs to compile libraries twice on some platforms (once to create position-independent code (PIC) for .so (shared) libraries, once to create code which is not PIC for .a (static) libraries).
What you may be seeing is the fact that gcov has issues with shared libraries. See "can gcov deal with shared object?" for details.
If that doesn't fix it, I'll have to agree with Brett that you ned to supply more info.
I got 10 C files.
10 h files all in one folder.
I need those files to create 1 executable in the same folder using unix makefile.
EDIT :
the soultion
create a file named "makefile"
write the following make sure you have a single TAB before the word "gcc" this will create a.out executable
all:
gcc *.c
if you need flags just add them for example to make the filename BOB:
all:
gcc *.c -o BOB
I don't think you want what you say you want, but how about:
all:
gcc *.c
"missing separator" is commonly caused by a missing tab in front of a command line. The lines with $(CXX) need to be indented by a tab - not 8 spaces, not any number of spaces, but a tab.
Additionally, I don't think that empty lines between rule and commands are allowed.
Apart from obviously writing the Makefile yourself, you can also use CMake which is a convenient build system generator.
A simple example of a CMakeLists.txt file:
cmake_minimum_required(VERSION 2.6)
project(yourproject C)
add_executable(yourexecutable file1.c file1.h file2.c file2.h ...)
You can then do in a terminal:
$ cmake .
$ make
and your executable will be built.
Be careful however that the generated makefile uses cmake and is therefore not distributable per se.
I am using WINAVR to progam an Amtel ATMEGA328 Chip.
I am trying to Link a library to my file but I am not sure exactly how to do it, and what I need to edit in the make file.
I have a lcd_lib.h and lcd_lib.c file that I want to include
in my main.c i have #include "lcd_lib.h";
and I have those files in the same directory as my make filer & main.c file.
Jeeze I am so used to being spoilt with C# and Java
My Solution:
in the make file:
find the line
SRC = $(TARGET).c [ADD FILENAME HERE]
so mine was:
SRC = $(TARGET).c lcd_lib.c
This is the first time I install a library. I followed the instructions here. It's from an online course on programming.
I'm not very Unix savvy. When I tried to compile one of the sample c files, one that #includes the cs50.h file, I get:
cc1: error: /usr/local/include: not a directory
Also, if I write cd /usr/local/include or cd /usr/local/lib, it tells me it's not a directory again, even though when I ls /usr/local they both show up.
Any ideas?
Given that the instructions in the header are:
To compile as a static library on your own system:
% gcc -c -ggdb -std=c99 cs50.c -o cs50.o
% ar rcs libcs50.a cs50.o
% rm -f cs50.o
% cp cs50.h /usr/local/include
% cp libcs50.a /usr/local/lib
Note the use of '%' as a prompt. It indicates that the operations should be done as root.
Unless your system is misconfigured, you will need to use root privileges to copy the files into the directories under /usr/local. For example, you might use sudo as a prefix to the commands:
sudo cp cs50.h /usr/local/include
sudo cp libcs50.a /usr/local/lib
We can deduce (with fairly high confidence) that you did not already have directories /usr/local/include and /usr/local/lib, and that you now have two files (not directories) called:
/usr/local/include that contains the header cs50.h
/usr/local/lib that contains the static library
You should validate this observation with ls -l /usr/local and perhaps file /usr/local/*. Then you should remove the files, create the directories, and copy the files into the newly created directories.
The only thing this explanation does not account for is the missing leading slash in the error message (which originally said 'cc1: error: usr/local/include: not a directory'). At the moment, I put that down to a transcription error in asking this question. (And a comment and edit confirms that diagnosis.)