On Sat, Apr 10, 2010 at 10:14 PM, Jesus Sanchez <zexe...@gmail.com> wrote: > El 11/04/2010 6:14, Jesus Sanchez escribis: >> >> This is not really OpenBSD related but since it's a UNIX-like OS and >> here are really experienced people coding in C I thought this was a good >> place to ask. >> >> Coding some simple stuff in C I ended up having a harmless mistake (I >> hope) a double-declared variable with different types (char and int for >> the example) in wich I did assignements beyond the bounds of the type >> size. Let's call it foo, declared in files compiled separatedly. Also >> say that everything it's compiled with gcc -c option (exect the final >> executable) without warnings of any kind: >> >> file a.c contains "char foo" on the code. >> and b.c contains "int foo" on the code. >> >> on the b.c file I made an assignement bigger than de byte limit, >> let's say 0x2211 for the example. Back to a.c later than the 0x2211 >> assignement I printed the variable and showed 0x11 (at that point i >> realized the mistake). But I was just wondering where the h*ll went the >> 0x22 bits on the memory?? I mean, the code reserved 1 byte as foo was >> declared as a char, and I assined there more than expected (0x2211 for >> example). >> >> I know the rigth thing is to declare the variable 'foo' on a header >> file and include it in all my code but I was just curious, what happends >> to the upper 0x22 ?? Was I accessing to a ilegal zone of memory?? the >> code executed without any error :o and the compiler showed no warning. >> >> Thanks for your time, and sorry for my english. >> -J >> > > OK, doing a deep search I found this (think that my > foo variable is the symbol the quote talks about): > > ------------------------------------------------------------------ > > .comm declares a common symbol named symbol. When linking, a common symbol > in one object file may be merged with a defined or common symbol of the same > name in another object file. If ld does not see a definition for the > symbol--just one or more common symbols--then it will allocate length bytes > of uninitialized memory. length must be an absolute expression. If ld sees > multiple common symbols with the same name, and they do not all have the > same size, it will allocate space using the largest size. > > When using ELF, the .comm directive takes an optional third argument. This > is the desired alignment of the symbol, specified as a byte boundary (for > example, an alignment of 16 means that the least significant 4 bits of the > address should be zero). The alignment must be an absolute expression, and > it must be a power of two. If ld allocates uninitialized memory for the > common symbol, it will use the alignment when placing the symbol. If no > alignment is specified, as will set the alignment to the largest power of > two less than or equal to the size of the symbol, up to a maximum of 16. > > > seen on: > http://stackoverflow.com/questions/501105/gcc-generated-assembly-comm > --------------------------------------------------------------------- > > so regarding my question, ld will use the largest memory space found as a > .comm foo, > so no harm at all with this mistake :D
i don't think so. Use gdb and see where you are writing to. Based on your description of your a.c and b.c, I assume in a.c you have "char foo;" (global), and in b.c you by mistake have "extern int foo;". If your foo variable is at address, say 0x11111111, and you write two bytes to that address, where foo is in fact a char (single byte), the other byte will be written to address 0x11111112. You can test this with a simple example program, where you can declare other char variables around your foo variable and print all of them after the foo assignment and see which ones got clobbered. Then again, maybe I'm misunderstanding your initial problem, you didn't show your code. --patrick Breakpoint 1, main (argc=1, argv=0xfffc8c8c) at a.c:30 30 bar(); (gdb) p &f $1 = (int *) 0x1842116 (gdb) x/4b 0x1842116 0x1842116 <f>: 0x00 0x00 0x00 0x00 bar () at b.c:14 14 f = 0x44332211; (gdb) n 16 } (gdb) x/4b 0x1842116 0x1842116 <f>: 0x44 0x33 0x22 0x11 (gdb) p &g $2 = 0x1842117 "3\"\021" (gdb) p &k $3 = 0x1842119 "\021" (gdb) p &l $4 = 0x1842118 "\"\021" (gdb) p/x f $13 = 0x44332211 (gdb) p/x g $14 = 0x33 (gdb) p/x l $15 = 0x22 (gdb) p/x k $16 = 0x11 Looks like the "extern int foo;" confused gdb. > > thanks for your time anyway. > -J
