EmbLogic's Blog

CRAMFS was written by Linus Torvalds as a filesystem with a bare minimum feature set. It is a very simple, and sometimes simplistic, compressed and read-only filesystem aimed at
embedded systems

CRAMFS has the following limitations:

• The maximum size a file can have is 16 MB.
• There are no current (.) or parent (..) directory entries.
• The UID field for files is 16 bits wide and the GID field is 8 bits wide. Normal filesystems
• usually support either 16- or 32-bit UIDs and GIDs. On CRAMFS, GIDs are truncated to the lower 8 bits. In other words, the maximum GID usable in a root filesystem built on CRAMFS is 255

To create cramfs do following.

• Goto to  <path to kernel>scripts/cramfs
• make
• Now, copy cramfsck mkcramfs  to an appropriate directory.
• Now create image using these tools like

mkcramfs rootfs  / images/cramfs.img

• With the filesystem image ready, we can now write it to our storage device

cat rootfs/cramfs.img > /dev/mtd4

$make

Error :

In file included from contrib/elftrunc.c:5:
/home/Amit/control-project/daq-module/build-tools/dietlibc-0.21/include/stdio.h:18: warning: ‘malloc’ attribute ignored
contrib/elftrunc.c: In function ‘main’:
contrib/elftrunc.c:141: warning: implicit declaration of function ‘memcmp’
contrib/elftrunc.c:145: warning: implicit declaration of function ‘strncpy’
contrib/elftrunc.c:145: warning: incompatible implicit declaration of built-in function ‘strncpy’

$ make CROSS_COMPILE=arm-uclibc-

Error : Help me out

ld: ldso.o: Relocations in generic ELF (EM: 40)
ld: ldso.o: Relocations in generic ELF (EM: 40)
ldso.o: could not read symbols: File in wrong format
make[2]: *** [lib] Error 1
make[2]: Leaving directory `/home/Amit/control-project/daq-module/build-tools/uClibc-0.9.16/ldso/ldso’
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/Amit/control-project/daq-module/build-tools/uClibc-0.9.16/ldso’
make: *** [_dir_ldso] Error 2

Assienment1.
1 #include:-
In ‘C’ programming language all library functions are included in different header files in different categories with “.h” extension.

# is called as “preprocessor”. Means it will include the header file before comipling the code. “include” gives command to include something   .

“stdio” stands for “standard input output”.

2.comment:-
A “comment” is a sequence of characters beginning with a forward slash/asterisk combination (/*) that is treated as a single white-space character by the compiler and is otherwise ignored. A comment can include any combination of characters from the representable character set, including newline characters, but excluding the “end comment” delimiter (*/).
The Microsoft compiler also supports single-line comments preceded by two forward slashes (//)
example :-
/* Comments can contain keywords such as
for and while without generating errors. */
and
// This is a valid comment

i faced a problem …when i did “make all” in gcc compilation(in build-gcc directory)…i got a error…No target is specified or Makefile is missing….but when i did make all-gcc,then it has done succesfully with no errors…m waiting for ryt ans…

Structure of a Function

A general form of a C function looks like this:

FunctionName (Argument1, Argument2, Argument3……)
{
Statement1;
Statement2;
Statement3;
}

An example of function.

int sum (int x, int y)
{
int result;
result = x + y;
return (result);
}

??

(gdb) backtrace
#0  func2 (x=30) at test.c:5
#1  0x80483e6 in func1 (a=30) at test.c:10
#2  0x8048414 in main (argc=1, argv=0xbffffaf4) at test.c:19
#3  0x40037f5c in __libc_start_main () from /lib/libc.so.6
(gdb)

?
Use the gdb command frame. 

Notice in the backtrace above that each frame has a number beside 

it. Pass the number of the frame you want as an argument to the 

command.
 
 

(gdb) frame 2
#2  0x8048414 in main (argc=1, argv=0xbffffaf4) at test.c:19
19        x = func1(x);
(gdb) 

							

?

Use the gdb command backtrace. In the backtrace below, we can see that we are currently inside func2(), which was called by func1(), which was called from main()

(gdb) backtrace
#0  func2 (x=30) at test.c:5
#1  0x80483e6 in func1 (a=30) at test.c:10
#2  0x8048414 in main (argc=1, argv=0xbffffaf4) at test.c:19
#3  0x40037f5c in __libc_start_main () from /lib/libc.so.6

A Debugging Symbol Table maps instructions in the compiled binary program to their corresponding variable, function, or line in the source code. This mapping could be something like:

• Program instruction => item name, item type, original file, line number defined.

Symbol tables may be embedded into the program, or stored as a separate file. So if you plan to debug your program then it is required to create Symbol table which will have required information to debug the program.

We can infer a few facts about symbol tables:

• A symbol table works for a particular version of the program –if the program changes, a new table must be made.
• Debug builds are often larger and slower than retail (non-debug) builds; debug builds contain the symbol table and other ancillary information.
• If you wish to debug a binary program you did not compile yourself, you must get the symbol tables from the author.

First when you write your c, c++ program your symbol table shows as :-

gcc -c hello1 hello.c

objdump -t hello.o  //  objdump command analysis object file and -t is a option to show symbol table.

hello.o:     file format elf32-i386

SYMBOL TABLE:
00000000 l    df *ABS*    00000000 hello.c
00000000 l    d  .text    00000000 .text
00000000 l    d  .data    00000000 .data
00000000 l    d  .bss    00000000 .bss
00000000 l    d  .rodata    00000000 .rodata
00000000 l    d  .note.GNU-stack    00000000 .note.GNU-stack
00000000 l    d  .comment    00000000 .comment
00000000 g     F .text    00000054 main
00000000         *UND*    00000000 printf

When you add -g option for de bugging in you program like:-

gcc -g -c hello hello.c

symbol table looks as :-

objdump -t hello.o

hello.o:     file format elf32-i386

SYMBOL TABLE:
00000000 l    df *ABS*    00000000 hello.c
00000000 l    d  .text    00000000 .text
00000000 l    d  .data    00000000 .data
00000000 l    d  .bss    00000000 .bss
00000000 l    d  .debug_abbrev    00000000 .debug_abbrev
00000000 l    d  .debug_info    00000000 .debug_info
00000000 l    d  .debug_line    00000000 .debug_line
00000000 l    d  .rodata    00000000 .rodata
00000000 l    d  .debug_frame    00000000 .debug_frame
00000000 l    d  .debug_loc    00000000 .debug_loc
00000000 l    d  .debug_pubnames    00000000 .debug_pubnames
00000000 l    d  .debug_aranges    00000000 .debug_aranges
00000000 l    d  .debug_str    00000000 .debug_str
00000000 l    d  .note.GNU-stack    00000000 .note.GNU-stack
00000000 l    d  .comment    00000000 .comment
00000000 g     F .text    00000054 main
00000000         *UND*    00000000 printf

The toolchains were build from the following sources:

- binutils-2.11.2.tar.gz
- gcc-2.95.3.tar.gz
- gcc-2.95.3.diff.bz2 (a re-diffed version of Phil Blundell’s diff)
- glibc-2.2.3.tar.gz
- glibc-linuxthreads-2.2.3.tar.gz
- linux-2.4.6.tar.gz
- patch-2.4.6-rmk2.gz
- diff-2.4.6-rmk2-np1.gz

Sources :

linux-2.4.6.tar.gz

http://www.kernel.org/pub/linux/kernel/v2.4/

patch-2.4.6-rmk2.gz

http://ftp.linux.org.uk/pub/linux/arm/kernel/v2.4/

diff-2.4.6-rmk2-np1.gz
ftp://ftp.arm.linux.org.uk/pub/armlinux/people/nico/v2.4/

gcc-2.95.3.diff.bz2

http://ftp.arm.linux.org.uk/pub/armlinux/toolchain/src-2.95.3/

binutils-2.11.2.tar.gz

http://ftp.gnu.org/gnu/binutils/

gcc-2.95.3.tar.gz

http://ftp.gnu.org/gnu/gcc/

glibc-2.2.3.tar.gz
glibc-linuxthreads-2.2.3.tar.gz

http://ftp.gnu.org/gnu/glibc/?

decl.c: In function 'start_struct':
decl.c:4451: error: argument 'code' doesn't match prototype
ch-tree.h:736: error: prototype declaration
make[2]: *** [decl.o] Error 1
make[2]: Leaving directory `/home/cihan/gcc-2.95.3/gcc/ch'
make[1]: *** [cc1chill] Error 2
make[1]: Leaving directory `/home/cihan/gcc-2.95.3/gcc'
make: *** [all-gcc] Error 2

why the implementation of large files under /proc is a little awkward ?

what is benefits of using seq_file interface over /pro file systems ?

scull_follow pointer is defined as:

dptr=scull_follow(localptr,item);

here localptr is struct scull_dev pointer and item is an integer value giving us 1 less than the total number of qsets required.

This is the message i get,when i comment the scull_follow pointer:

make  -C /lib/modules/2.6.32.16-150.fc12.i686.PAE/build M=/project/13oct modules
make[1]: Entering directory `/usr/src/kernels/2.6.32.16-150.fc12.i686.PAE’
CC [M]  /project/13oct/asng1.o
/project/13oct/asng1.c: In function ‘scull_write’:
/project/13oct/asng1.c:220: warning: ‘dptr’ is used uninitialized in this function
/project/13oct/asng1.c: In function ‘scull_read’:
/project/13oct/asng1.c:180: warning: ‘dptr’ may be used uninitialized in this function
Building modules, stage 2.
MODPOST 1 modules
WARNING: “__moddi3″ [/project/13oct/asng1.ko] undefined!
CC      /project/13oct/asng1.mod.o
LD [M]  /project/13oct/asng1.ko
make[1]: Leaving directory `/usr/src/kernels/2.6.32.16-150.fc12.i686.PAE’

This is the message i get when i uncomment the scull_follow pointer:

make  -C /lib/modules/2.6.32.16-150.fc12.i686.PAE/build M=/project/13oct modules
make[1]: Entering directory `/usr/src/kernels/2.6.32.16-150.fc12.i686.PAE’
CC [M]  /project/13oct/asng1.o
Building modules, stage 2.
MODPOST 1 modules
WARNING: “__moddi3″ [/project/13oct/asng1.ko] undefined!
WARNING: “__divdi3″ [/project/13oct/asng1.ko] undefined!
CC      /project/13oct/asng1.mod.o
LD [M]  /project/13oct/asng1.ko
make[1]: Leaving directory `/usr/src/kernels/2.6.32.16-150.fc12.i686.PAE’

This is the code for scull_follow:

scull_qset* scull_follow(Scull_dev *localptr,int n)
{

scull_qset *qs;
qs=localptr->data;     /**/

if(qs==NULL)    /* means ki qs k pass address nai hai */
{
qs=localptr->data=kmalloc(sizeof(scull_qset),GFP_KERNEL);/* here we r creating a struct scull_qset */
if(qs==NULL)
{
return NULL;
}
memset(qs,”,sizeof(scull_qset));
}

while(n>0)
{
if(qs->next==NULL)
{
qs->next=kmalloc(sizeof(scull_qset),GFP_KERNEL);
if(qs->next==NULL)
{
return NULL;
}
memset(qs->next,”,sizeof(scull_qset));
}
qs=qs->next;
n–;
}
return qs;

}