avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] avr-as and debugging symbols


From: manders1
Subject: Re: [avr-gcc-list] avr-as and debugging symbols
Date: Tue, 1 Jul 2003 06:30:45 -0400

> In article <address@hidden> you write:
> 
> >Here's some output from "avr-gcc -S -g test.c" that shows
> >the syntax I was trying to assemble.
> 
> Except of the extraneous line breaks apparently introduced by your
> news/mail software, this is supposed to work.  I've successfully used
> own .stabs data type definitions like this myself:
> 
> .stabs           "unsigned int:t1=r1;0;65535;",128,0,0,0
> .stabs           "unsigned char:t2=r2;0;255;",128,0,0,0
> .stabs           "unsigned 
> long:t3=r3;0000000000000;0037777777777;",128,0,0,0
> ..
> 
>                  .section .bss
>                  .global                 adcptr
>                  .stabs          "adcptr:G10=*1",32,0,0,0
> adcptr:          .word           0
> 
> In a C context, this would be
> 
> int *adcptr;
> 
> What's the exact error message you're getting (including the line
> number it refers to)?
> 
> -- 
> J"org Wunsch Unix support engineer
> address@hidden http://www.interface-systems.de/~j/

I went back and tried to reproduce the problem but
was unable to get an error message.  However, what
I still don't understand is that if I declare some
.stabs like those above they do not seem to appear
in the object or executable images, I tried using
avr-objdump and avr-readelf to no avail.  I even
tried strings but found nothing.  OTOH, if I use
avr-objdump on an object created by avr-gcc I can
see some information but not what I expect.

For instance, here is an excerpt from the output of
"avr-gcc -g -S" from the .s file:

    .stabs  "gcc2_compiled.",60,0,0,0
    .stabs  "int:t(0,1)=r(0,1);-32768;32767;",128,0,0,0
    .stabs  "char:t(0,2)=r(0,2);0;127;",128,0,0,0

However, these symbols don't appear in the executable
when doing an "avr-objdump -g".  What does appear are
things like:

    typedef int16 int;
    typedef int8 char;
    typedef int32 long int;

The debugging information reported by these programs
doesn't seem to bear a resemblance to what the source
assembly code shows.

--
mark anderson
address@hidden


reply via email to

[Prev in Thread] Current Thread [Next in Thread]