extern variable

extern variable

[sumanth]

Hi,
     How can I make sure the debugging  information printed by my 
compiler for extern variables is correct.
     I am able to print them in gdb in with an _ (underscore). I am 
using Gcc-4.3.4 and gdb 5.3

Thanks,
Sumanth G 

Re: extern variable

[Michael Eager]

sumanth wrote:
> Hi,
>     How can I make sure the debugging  information printed by my 
> compiler for extern variables is correct.

Make sure you compile with -g.  If you don't generate
debug info for the variable, gdb will default to printing
it as an unknown symbol.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: extern variable

[Jim Wilson]

On 07/30/2009 07:38 AM, sumanth wrote:
> How can I make sure the debugging information printed by my compiler for
> extern variables is correct.
> I am able to print them in gdb in with an _ (underscore). I am using
> Gcc-4.3.4 and gdb 5.3

ELF targets usually don't prepend an underscore to symbol names.  But if 
you are prepending an underscore for some reason, then you need to make 
sure that your ASM_OUTPUT_* macros handle this correctly.  You set 
USER_LABEL_PREFIX to an underscore, and then you add the 
USER_LABEL_PREFIX unless the symbol name starts with '*'.  See the 
ASM_GENERATE_INTERNAL_LABEL docs.  This stuff can be tricky.  You will 
probably have to step through your cc1 port in gdb to see exactly what 
is going on.  It will be useful to look at an existing port that handles 
this correctly; step through it in gdb to see how it works.

Jim

Re: extern variable

[sumanth]

Jim,
      If I  define USER_LABEL_PREFIX "" and declare a global variable 
using names r0/r1...r15 ( my register names ) , my assembler is 
generating an error message saying " r0 is already defined , cannot use 
register in expression " ........

       How can i make sure my tool chain knows the difference between 
global variable r0 and register r0.

Regards,
Sumanth G
      

Jim Wilson wrote:
> On 07/30/2009 07:38 AM, sumanth wrote:
>> How can I make sure the debugging information printed by my compiler for
>> extern variables is correct.
>> I am able to print them in gdb in with an _ (underscore). I am using
>> Gcc-4.3.4 and gdb 5.3
>
> ELF targets usually don't prepend an underscore to symbol names.  But 
> if you are prepending an underscore for some reason, then you need to 
> make sure that your ASM_OUTPUT_* macros handle this correctly.  You 
> set USER_LABEL_PREFIX to an underscore, and then you add the 
> USER_LABEL_PREFIX unless the symbol name starts with '*'.  See the 
> ASM_GENERATE_INTERNAL_LABEL docs.  This stuff can be tricky.  You will 
> probably have to step through your cc1 port in gdb to see exactly what 
> is going on.  It will be useful to look at an existing port that 
> handles this correctly; step through it in gdb to see how it works.
>
> Jim
>
>

Re: extern variable

[Jim Wilson]

On Mon, 2009-08-03 at 09:44 +0530, sumanth wrote:
>        How can i make sure my tool chain knows the difference between 
> global variable r0 and register r0.

The simple solution is to either add a prefix to variable names, or to
add a prefix to register names.  In ELF, the convention is to not add a
prefix to variables names, we add a prefix to register names instead if
we need one, e.g. %eax on i386, or $4 on mips.

You can of course choose to add a prefix to variable names.  It just
isn't the convention.  See for instance how the arm-elf port works when
you use the -fleading-underscore option.

A less simple solution is to have an assembler syntax that avoids
ambiguity between register names and variable names.  If for instance
you have a move instruction that can accept either a register or a
variable as source, then you have an ambiguity.  You could instead have
a load instruction for reading memory, and a move instruction for
reading registers, and then you don't have an ambiguity anymore.  You
can also do things with addressing modes and relocation operators to
reduce ambiguities.

Jim

Re: extern variable

[sumanth]

Hi Jim,
that seems to be a promising solution.
If I keep the prefix "_" for a global variable , there is a problem in 
accessing it in gdb...let me explain you with an example

Eg: file1.c
int a = 10;
int main()
{
int b =10;
int c;
c = add( a , b);
return 0;
}

file2.c

int add( int x, int y)
{
return x+y ;
}

 > mycompiler-gcc -g file1.c file2.c
 > mycompiler-gdb a.out
  >> when i print "a" in file1.c , i am able to see value 10;
  >> when i print "a" int file2.c, it prints , no symbol defined. 
Instead I can access it with " print _a"

Thats the problem; guess i am clear this time.

prefixing registers is out of scope for me , as people got used to 
register names r0, r1......

Regards,
Sumanth G

Jim Wilson wrote:
> On Mon, 2009-08-03 at 09:44 +0530, sumanth wrote:
>   
>>        How can i make sure my tool chain knows the difference between 
>> global variable r0 and register r0.
>>     
>
> The simple solution is to either add a prefix to variable names, or to
> add a prefix to register names.  In ELF, the convention is to not add a
> prefix to variables names, we add a prefix to register names instead if
> we need one, e.g. %eax on i386, or $4 on mips.
>
> You can of course choose to add a prefix to variable names.  It just
> isn't the convention.  See for instance how the arm-elf port works when
> you use the -fleading-underscore option.
>
> A less simple solution is to have an assembler syntax that avoids
> ambiguity between register names and variable names.  If for instance
> you have a move instruction that can accept either a register or a
> variable as source, then you have an ambiguity.  You could instead have
> a load instruction for reading memory, and a move instruction for
> reading registers, and then you don't have an ambiguity anymore.  You
> can also do things with addressing modes and relocation operators to
> reduce ambiguities.
>
> Jim
>
>
>
>
>   

Re: extern variable

[Jim Wilson]

On Tue, 2009-08-04 at 00:06 +0530, sumanth wrote:
>  > mycompiler-gcc -g file1.c file2.c
>  > mycompiler-gdb a.out
>   >> when i print "a" in file1.c , i am able to see value 10;
>   >> when i print "a" int file2.c, it prints , no symbol defined. 
> Instead I can access it with " print _a"

This sounds odd, as there is no variable a or _a in file2.c, and if you
can see a variable in one file you should be able to see if with the
same name in another file.

Anyways, I think I already answered this with my first message when I
pointed you at ASM_OUTPUT_* and ASM_GENERATE_INTERNAL_LABEL etc.  If you
compile with -g -S, and look at the assembly language, you will see that
"_a" is being used in the debug info someplace for the variable name
where "a" should be used instead.  "_a" is correct for the variable
address, but not the variable name.  So you will have to step through
your gcc port to figure out why the "_a" is incorrectly printed, and
most likely it is a bug in one of the macros I have mentioned.  Take a
look at a port that handles this correctly to see what they do
differently to make this work.

Jim

Re: extern variable

[sumanth]

Hi jim ,
    forgot to mention , I am accessing variable a as extern in file2.c
    I am going through the solutions pointed by you but not able to 
figure out one .


Thanks ,
Sumanth G

Jim Wilson wrote:
> On Tue, 2009-08-04 at 00:06 +0530, sumanth wrote:
>   
>>  > mycompiler-gcc -g file1.c file2.c
>>  > mycompiler-gdb a.out
>>   >> when i print "a" in file1.c , i am able to see value 10;
>>   >> when i print "a" int file2.c, it prints , no symbol defined. 
>> Instead I can access it with " print _a"
>>     
>
> This sounds odd, as there is no variable a or _a in file2.c, and if you
> can see a variable in one file you should be able to see if with the
> same name in another file.
>
> Anyways, I think I already answered this with my first message when I
> pointed you at ASM_OUTPUT_* and ASM_GENERATE_INTERNAL_LABEL etc.  If you
> compile with -g -S, and look at the assembly language, you will see that
> "_a" is being used in the debug info someplace for the variable name
> where "a" should be used instead.  "_a" is correct for the variable
> address, but not the variable name.  So you will have to step through
> your gcc port to figure out why the "_a" is incorrectly printed, and
> most likely it is a bug in one of the macros I have mentioned.  Take a
> look at a port that handles this correctly to see what they do
> differently to make this work.
>
> Jim
>
>
>
>
>