the following code does'nt produce any warning when compiled with "-Wall" option in gcc:
int main ()
{
int c, i;
for ( ; i < 10; i++ ) {
c += i;
}
return c;
}
This is the command used to build the source:
$ gcc -c -Wall 1.c
$
It returns without any message.
I would expect a "warning: āiā is used uninitialized in this function", and the same warning for the 'c' variable.
Any idea about this behavior?
Thank you.
Analysis performed by -Wall is very limited without optimizations. Warning is successfully detected with -O1 or -O2.
I am trying to add pdfium.lib library in a small program in windows. The program is...
#include <fpdfview.h>
int main() {
FPDF_LIBRARY_CONFIG config;
config.version = 2;
config.m_pUserFontPaths = NULL;
config.m_pIsolate = NULL;
config.m_v8EmbedderSlot = 0;
FPDF_InitLibraryWithConfig(&config);
FPDF_DestroyLibrary();
return 0;
}
Pdfium.lib has build as complete lib and runs ok in Linux.(pdf_is_complete_lib = true).
When linking in GCC with the "-pg -s -Wl,--start-group pdfium.a -Wl,--end-group -lpthread" parameters works fine in Linux.
But in Windows10 with "-pg -s -Wl,--start-group pdfium.lib -Wl,--end-group -lpthread" parameters. Program say "main.cpp|7|undefined reference to `FPDF_InitLibrary'|, .... ||error: ld returned 1 exit status|
I am stack here in very simple program with main, because i am new to libs, so i need help.
I have also post the problem to google pdfium mailing list.
Thank you
Jim
But in windows i
I'm developing my own operating system. I have completed the boot sector and loaded my kernel successfully. My development environment is Ubuntu 14.04 and GCC 4.8. My kernel will run under BOCHS. I wanted to print a specific character in a specific position on the screen, so I created a function like this:
void print_char(char target, int col, int row, unsigned char attribute) {
//attribute controls the colour of the character
char * vidmem = (char *) VIDEO_ADDRESS; //#define VIDEO_ADDRESS 0xb8000
*vidmem = target;
//TODO: add other control statements
}
I call this function in my main function, which is the entry point of my kernel:
print_char('T', 0, 0, (unsigned char) 0x0f);
The code above is supposed to print the character 'T' at the top-left of the screen. It does't show up! After I changed the declaration of the print_char:
void print_char(char target, int col, int row, int attribute)
Or something like this:
void print_char(char target, int col, int row) then call it like print_char('T', 0, 0)
After I change it, everything works! I am really confused about this problem. Can any one explain it to me?
I have fix the problem by modify the flags of gcc and ld to generate a 32-bit .o file and '.bin' file (My ubuntu is a 64-bit version) by the following statemens.
%.o: %.c ${HEADERS}
gcc -ffreestanding -m32 -c $< ${CFLAG} -o $#
kernel.bin: kernel/kernel_entry.o ${OBJ}
ld -o $# -melf_i386 -Ttext 0x1000 $^ --oformat binary
where kernel_entry.o will make sure our routine finds the entry of main function in kernel code. then I get my os image by:
os-image: boot/boot_sect.bin kernel.bin
cat $^ > os-image
where boot_sect.bin plays the role of a boot sector.
But I still don't know why the 64-bit objective file will cause the phenomena I described above...
In searching the site, I found two other similar (at first glance) questions by users 2253605
and 2135159. I also have tried two different versions of gcc. This started out as a hard to
track problem in an application to keep various forms of data in sync on different media. I
eventually boiled it down to a few lines of code that illustrate the problem.
This one is very defined and puzzling. I have not been able to find a case where my system opens
a file, and returns a non-zero file descriptor. It sometimes does really open the specified file
and allows a subsequent read() to occur without error. But by the third open() the
subsequent read() fails, specifying an invalid argument, which can only be a zero value file
descriptor.
The code below tries to open 5 different files, 4 files exist and one that does not exist.
The first 4 opens all return a file descriptor value of zero (stdin).
stdin is not closed, a read() before the first open() or after any one of these open() calls,
will hang until enter is pressed.
Even if stdin were closed, zero should only be returned for the first open(). The
file descriptors are being set and when the open() for the non-existent file is attempted,
it returns an error.
I can't believe that gcc can't open a file. I think I have some kind of O/S-compiler configuration
issue (lib) or maybe I can't see the forest for the trees.
This is on ubuntu 12.04 LTS 64 bit and 64 bit gcc-4.6 also on gcc-4.7 . The flash drive is
formatted ext4. x86_64 intel processor. The installation commands used for gccc-4.7 on 2/10/16
are also shown below. Both gcc-4.6 and gcc-4.7 give identical results. The makefile
is at the end.
Anybody know what's happening here?
The terminal output is shown below the code.
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h
#include <errno.h>
int main()
{
long ret_val;
char cpy_buf[4096];
char s_ary[20][80] =
{
"/media/FLASH16GB_2/Test_dir/t_dir/dm1", //0 exists
"/media/FLASH16GB_2/Test_dir/t_dir/dm2", //1 exists
"/media/FLASH16GB_2/Test_dir/t_dir/dm3", //2 exists
"/media/FLASH16GB_2/Test_dir/t_dir/dm4", //3 exists
"/media/FLASH16GB_2/Test_dir/t_dir/dm5", //4 does not exist
};
char *s1;
long s_fh_1, s_fh_2, s_fh_3, s_fh_4, s_fh_5;
s_fh_1 = 10000;
s1 = &s_ary[0][0];
if (s_fh_1 = open( s1 , O_RDONLY) < 0) // &s_ary[0][0]
{
printf("Error opening source file, name=%s, line# = %i, errno = %i \n",&s_ary[0][0], __LINE__ , errno);
return -1;
}
if (s_fh_2 = open( &s_ary[1][0], O_RDONLY) < 0)
{
printf("Error opening source file, name=%s, line# = %i, errno = %i \n",&s_ary[1][0], __LINE__ , errno);
return -1;
}
if (s_fh_3 = open( &s_ary[2][0], O_RDONLY,0) < 0)
{
printf("Error opening source file, name=%s, line# = %i, errno = %i \n",&s_ary[2][0], __LINE__ , errno);
return -1;
}
if (s_fh_4 = open( &s_ary[3][0], O_RDONLY,0) < 0)
{
printf("Error opening source file, name=%s, line# = %i, errno = %i \n",&s_ary[3][0], __LINE__ , errno);
return -1;
}
printf("s_fh_1 = %li, s_fh_2 = %li, s_fh_3 = %li, s_fh_4 = %li \n", s_fh_1, s_fh_2, s_fh_3, s_fh_4);
if (s_fh_5 = open( &s_ary[4][0], O_RDONLY,0) < 0)
{
printf("Error opening source file, name=%s, line# = %i, errno = %i \n",&s_ary[4][0], __LINE__ , errno);
return -1;
}
return 0;
}
terminal output:
$ make
gcc -g -c -std=iso9899:1999 -o obj/bug_tst_sync_m.o bug_tst_sync_m.c -I../include
gcc -o bug_tst_sync_m obj/bug_tst_sync_m.o -I../include -L /usr/lib64/X11 -lX11 -lm
$ ./bug_tst_sync_m
s_fh_1 = 0, s_fh_2 = 0, s_fh_3 = 0, s_fh_4 = 0
Error opening source file, name=/media/FLASH16GB_2/Test_dir/t_dir/dm5, line# = 88, errno = 2
$
$
gcc-4.7 installation commands used on 2_10_16.
update-alternatives --display gcc
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install gcc-4.7
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.7 60
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 40
sudo update-alternatives --config gcc
makefile
### where to look for include files ( locally and globally ? -I /usr/include/X11)
IDIR =../include
### compiler to runand generate debugging info (no -g for production release code)
CC=gcc -g
### list of dependencies
CFLAGS=-I$(IDIR)
### where to put object modules
ODIR=obj
### where to look for local library files locally (or write?)
LDIR = -L /usr/lib64/X11 -lX11
### libraries to include m=-lm includes the math libarary, math lib = -lm
LIBS=-lm
### list of all dependency files (.h files)
_DEPS = queues.h InterlockedExchange.h
DEPS = $(patsubst %,$(IDIR)/%,$(_DEPS))
### list of all object files
_OBJ = bug_tst_sync_m.o
OBJ = $(patsubst %,$(ODIR)/%,$(_OBJ))
### compiles object modules and produces debug info
$(ODIR)/%.o: %.c $(DEPS)
$(CC) -c -std=iso9899:1999 -o $# $< $(CFLAGS)
### left side of colon is executable name
### this line links objects and creates the executable
bug_tst_sync_m: $(OBJ)
gcc -o $# $^ $(CFLAGS) $(LDIR) $(LIBS)
### this gets run if you type "make clean". it deletes source backup and object files.
### run this then next make does everything. Without this you get situations that
.PHONY: clean
clean:
rm -f $(ODIR)/*.o *~ core $(INCDIR)/*~
Your problem is operator precedence, < binds harder than =;
if ( s_fh_1 = open(s1 , O_RDONLY) < 0 )
becomes
if ( s_fh_1 = ( open(s1 , O_RDONLY) < 0 ) )
which means, if open returns a number greater than or equal to zero, s_fh_1 will be 0.
I met a problem when inspecting the local variables of user space application in systemtap.
I write a test.c like this:
#include <stdio.h>
int func(int *p, int val)
{
printf("p=%p val=%d\n", p, val);
return 1;
}
int main()
{
int a = 7;
func(&a, a);
return 0;
}
and compile it with -g
# gcc -g -o test test.c
Systemtap can see the variable of func(): p and val
# stap -L 'process("./test").function("func")'
process("/home/ryan/Public/test").function("func#/home/ryan/Public/test.c:3") $p:int* $val:int
So I use this stp to watch the variables:
# stap -e 'probe process("./test").function("func") {printf("%s(%p, %d)\n", probefunc(), $p, $val)}'
But the local variables are not right in the result when test program executed, it shows:
func(0x0, 0)
I am using fedora19 with:
kernel-3.11.9-200.fc19.x86_64
systemtap-sdt-devel-2.3-1.fc19.x86_64
systemtap-2.3-1.fc19.x86_64
systemtap-client-2.3-1.fc19.x86_64
systemtap-devel-2.3-1.fc19.x86_64
systemtap-runtime-2.3-1.fc19.x86_64
gcc-4.8.2-7.fc19.x86_64
Could someone meet this problem or give me a solution?
.function probes are defined to fire at entry to the function. If you're looking for values of local variables, you need to use .statement probes, identifying the source-file:line-number. In this case though, you're looking for parameters to a function (which happened to be based on another function's locals). In this case, the .function probe is appropriate.
You appear to be hitting a GCC bug. In plain -g mode (ironically), dwarf debuginfo is sometimes inaccurate for incoming function parameters. Try "gcc -g -O" or "gcc -g -O2" instead. Systemtap prologue-searching (stap -P) might help. See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358, https://sourceware.org/bugzilla/show_bug.cgi?id=13420
In case the "stap -P" doesn't help, you may need to resort to statement-level probing after all:
probe process("./test").statement("func#test.c:5") { println($$parms) }
(line :5 refers to the printf)