[Bug target/17994] avr-gcc does not output a dwarf2 .debug_frame section

2009-10-23 Thread tsandnes at atmel dot com


--- Comment #3 from tsandnes at atmel dot com  2009-10-23 11:41 ---
I tried gcc 4.3.2 from the WinAVR distribution and also avr-gcc 4.4.1.

The short story is: There is call frame information there, but not enough.
Specifically, the Call Frame instructions to reconstruct the pc to unwind rule
table are still missing, but the CIE and FDE are present. 

I compared gcc and avr-gcc output on linux with the following results:

gcc:
---
The section .debug_frame contains:

 0010  CIE
  Version:   1
  Augmentation:  
  Code alignment factor: 1
  Data alignment factor: -4
  Return address column: 8

  DW_CFA_def_cfa: r4 (esp) ofs 4
  DW_CFA_offset: r8 (eip) at cfa-4
  DW_CFA_nop
  DW_CFA_nop

0014 0024  FDE cie= pc=08048394..0804840a
  DW_CFA_advance_loc: 4 to 08048398
  DW_CFA_def_cfa: r1 (ecx) ofs 0
  DW_CFA_register: r4 (esp) in r1 (ecx)
  DW_CFA_advance_loc: 6 to 0804839e
  DW_CFA_def_cfa: r4 (esp) ofs 4
  DW_CFA_advance_loc: 1 to 0804839f
  DW_CFA_def_cfa_offset: 8
  DW_CFA_offset: r5 (ebp) at cfa-8
  DW_CFA_advance_loc: 2 to 080483a1
  DW_CFA_def_cfa_register: r5 (ebp)
  DW_CFA_advance_loc: 1 to 080483a2
  DW_CFA_offset: r4 (esp) at cfa-12
  DW_CFA_nop
  DW_CFA_nop

003c 0014  FDE cie= pc=0804840a..0804841c
  DW_CFA_advance_loc: 1 to 0804840b
  DW_CFA_def_cfa_offset: 8
  DW_CFA_offset: r5 (ebp) at cfa-8
  DW_CFA_advance_loc: 2 to 0804840d
  DW_CFA_def_cfa_register: r5 (ebp)

---

avr-gcc 

---
 000c  CIE
  Version:   1
  Augmentation:  
  Code alignment factor: 1
  Data alignment factor: -1
  Return address column: 36

  DW_CFA_def_cfa: r32 ofs 0

0010 000c  FDE cie= pc=00ce..0160

0020 000c  FDE cie= pc=0160..018c

---


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17994



[Bug target/21119] New: avr-gcc does not output Dwarf 2 information to track optimized variables' locations

2005-04-20 Thread tsandnes at atmel dot com
The dwarf debug information has mechanisms for keeping track of variables whose
location changes during the execution of a program. This informationis stored in
an objectfile section called .debug_loc. This is not output by avr-gcc when
optimization is turned on and one should expect this information to be output.

-- 
   Summary: avr-gcc does not output Dwarf 2 information to track
optimized variables' locations
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsandnes at atmel dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: mingw32
  GCC host triplet: mingw32
GCC target triplet: AVR


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21119


[Bug target/21119] avr-gcc does not output Dwarf 2 information to track optimized variables' locations

2005-04-20 Thread tsandnes at atmel dot com


-- 
   What|Removed |Added

 CC||ericw at evcohs dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21119


[Bug debug/19885] [4.0/4.1 Regression] avr dwarf-2 support is broken for head 4.0/4.1

2005-03-16 Thread tsandnes at atmel dot com

--- Additional Comments From tsandnes at atmel dot com  2005-03-17 06:33 
---
For the 3.4.1, I am quite sure that no bugfixes were implemented to get Dwarf
support from avr-gcc. 

After configuring gcc like this:
 ./configure --enable-languages=c,c++ --target=avr --with-dwarf2 
and building it, the Dwarf support was generally ok. (Apart from the bugs I have
reported earlier)

Torleif

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885


[Bug target/19087] Overflowed address in dwarf debug line information

2005-03-10 Thread tsandnes at atmel dot com

--- Additional Comments From tsandnes at atmel dot com  2005-03-11 07:43 
---
 Here is the ELF file.  Runs on an ATmega128 using about 75% code space,
 almost all of 32k expanded SRAM and almost all of EEPROM.  I hope that this
 helps.  Please treat the file as confidential.

 BTW, I sent this from home because I didn't have the laptop with me at work
 today and figured this would help with the time zone differences, etc.
 Please make sure that any reply makes it to my work email in the CC.

I have had a quick look at the objectfile with
avr-readelf -w
and found that global and static variables are in locations that are way beyond
the atmega128's 4K of flash memory.

It seems that flash addresses in the debuginformation are no longer subtracted
by 0x80. (The flash offset used by avr-gcc)

For example, the last_baud_rate variable quite early in the objectfile is stated
to be at address 0x80019c:

2851: Abbrev Number: 21 (DW_TAG_variable)
 DW_AT_name: (indirect string, offset: 0x188): last_baud_rate
 DW_AT_decl_file   : 22
 DW_AT_decl_line   : 710
 DW_AT_type: 2c
 DW_AT_location: 5 byte block: 3 9c 1 80 0  (DW_OP_addr: 80019c)

Probably, 0x19c is the correct address.

If you can fix this, I think we are done. (except maybe for similar problems
with the eeprom segment)

Regards,

Torleif

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087


[Bug target/19087] Overflowed address in dwarf debug line information

2005-03-07 Thread tsandnes at atmel dot no

--- Additional Comments From tsandnes at atmel dot no  2005-03-08 07:07 
---
Subject: Re:  Overflowed address in dwarf debug line information


 I applied the GCC and binutil patches to ensure that my gcc is the same as 
 that 
 used in WinAVR Feb14/05 distribution.  I then built libc1.2.3 and clean built 
 my project.  Loaded it all into AS4.11 with the beta parser DLLs.  No 
 difference.
 
 With the 32 bit dwarf address, line number info seems ok, local automatic 
 variables seem ok but the static and global variables all appear as invalid 
 locations when hovering over them.
 
 I'll wait for any comments from Torleif as to whether this is at the AS4 
 parsing end or during one of the earlier stages (i.e. in GCC or binutils).

Great work!

If you could send me the object file , I could debug my 32-bit parser version 
to 
check out this problem with global/static data.

It is hard to make any statement on whether this is a parser or avr-gcc 
deficiency before investigating the object file.

Regards,

Torleif


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087


[Bug c/19087] New: Overflowed address in dwarf debug line information

2004-12-20 Thread tsandnes at atmel dot com
The mapping between addresses and code locations is invalid in object files
compiled for AVR targets that addresses code above 64K. This seems like a
rollover bug because addresses immediately above 64K have values near 0. 

To reproduce this bug, generate a source file that uses more than 64K of program
memory and try to parse the .debug_line section using libdwarf or by
implementing the state machine described in section 6.2 of DWARF Debugging
Information Format revision 2.0.0

This is probably a side-effect of the AVR usually only addressing 64K of program
memory. 
http://reality.sgi.com/davea/
http://dwarf.freestandards.org/modules.php?name=Contentpa=showpagepid=6

-- 
   Summary: Overflowed address in dwarf debug line information
   Product: gcc
   Version: 3.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsandnes at atmel dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: mingw32
  GCC host triplet: 386
GCC target triplet: AVR


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087


[Bug debug/19087] Overflowed address in dwarf debug line information

2004-12-20 Thread tsandnes at atmel dot no

--- Additional Comments From tsandnes at atmel dot no  2004-12-20 13:40 
---
Subject: Re:  Overflowed address in dwarf debug line information

pinskia at gcc dot gnu dot org wrote:
 --- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-20 
 12:53 ---
 Can you attach a preprocessed source?

Hmm, That will probably be a problem.
I have just piled together a lot of generated code and a library to be able to 
create an object with this much program memory. Would the preprocessed source 
(of the file with main()) be of use anyway?

The library is a trick to fool avr-gcc into creating the object without failing.
If I just put it all in one file and try to compile it I get errors like these:

 avr-gcc -Wall -gdwarf-2 -mmcu=atmega128 -O0 largeandsimple.c -o 
 largeandsimple.elf
c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccew.s: Assembler messages:
c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccew.s:55075: Error: value of 66702 too 
large for field of 2 bytes at 16
c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccew.s:92562: Error: value of 66702 too 
large for field of 2 bytes at 52828
c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccew.s:54188: Error: value of 65542 too 
large for field of 2 bytes at 10009
...

Hmm, come to think of it, maybe I should report this as a bug too?

Torleif


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087


[Bug debug/19087] Overflowed address in dwarf debug line information

2004-12-20 Thread tsandnes at atmel dot com

--- Additional Comments From tsandnes at atmel dot com  2004-12-20 14:02 
---
Created an attachment (id=7782)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7782action=view)
Preprosessed source of a large object file that fails to build for atmega128

Trying to produce a simple and independent test case to reproduce this bug, I
generated a lot of sourcecode and put it in one file. ( The goal was to get
above 64K). When compiling this file, i get this output from avr-gcc:

avr-gcc -Wall -gdwarf-2 -mmcu=atmega128 -O0 -save-temps largeandsimple.c -o
largeandsimple.elf
c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccUz.s: Assembler messages:
c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccUz.s:55075: Error: value of 66702 too
large for field of 2 bytes at 16
c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccUz.s:92562: Error: value of 66702 too
large for field of 2 bytes at 52836
c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccUz.s:54188: Error: value of 65542 too
large for field of 2 bytes at 10009


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087


[Bug target/19087] Overflowed address in dwarf debug line information

2004-12-20 Thread tsandnes at atmel dot com


-- 
   What|Removed |Added

  Component|debug   |target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087


[Bug target/19087] Overflowed address in dwarf debug line information

2004-12-20 Thread tsandnes at atmel dot no

--- Additional Comments From tsandnes at atmel dot no  2004-12-20 14:15 
---
Subject: Re:  Overflowed address in dwarf debug line information

pinskia at gcc dot gnu dot org wrote:
 --- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-20 
 14:05 ---
 Hmm, on the mainline I get an error about dwarf2 not being supported:
 t.c:1: error: target system does not support the dwarf-2 debug format

avr-gcc must be built with dwarf support to be able to produce objects with 
dwarf2 debugging information.

It is probably nececssary to build the entire toolchain from scratch.

Something like this.

1 cd binutils
2  ./configure --target=avr-elf --with-dwarf2
3 gmake
4 gmake install
5 cd ../gcc
6 ./configure --enable-languages=c,c++ --target=avr --with-dwarf2
7 gmake
8 gmake install
9 cd ../avr-libc
10 ./configure --prefix=/usr/local
11 gmake
12 gmake install

Are you familiar with the AVR port?

Thanks for looking into this!

Torleif


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087


[Bug debug/17993] New: Error in dwarf2 debug output of bitfield members

2004-10-14 Thread tsandnes at atmel dot com
avr-gcc-v:
Reading specs from c:/programs/WinAVR/bin/../lib/gcc/avr/3.4.1/specs
Configured with: ../gcc-3.4.1/configure --prefix=e:/avrdev/install
--build=mingw32 --host=mingw32 --target=avr --enable-languages=c,c++
Thread model: single
gcc version 3.4.1

command line:
avr-gcc -gdwarf-2 bitfieldbug.c  -o bf.elf

The debug output as shown by avr-readelf -w bf.elf shows that the first bitfield
member has a DW_AT_data_member_location of ff ff ff ff ff, which is obviously
wrong. 

This behaviour seems to persist no matter how I define the bitfield.

---source---
typedef struct
{
  int   j:5;
  int   k:6;
  int   m:5;
  int   n:8;
} faultybitfield_t; 

int main(int arcg, char **argv)
{
  faultybitfield_t bf;
  bf.j = 3;
  return 0;
}
---end source---

-- 
   Summary: Error in dwarf2 debug output of bitfield members
   Product: gcc
   Version: 3.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsandnes at atmel dot com
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: 386
GCC target triplet: AVR


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17993


[Bug debug/17994] New: avr-gcc does not output a dwarf2 .debug_frame section

2004-10-14 Thread tsandnes at atmel dot com
avr-gcc-v:
Reading specs from c:/programs/WinAVR/bin/../lib/gcc/avr/3.4.1/specs
Configured with: ../gcc-3.4.1/configure --prefix=e:/avrdev/install
--build=mingw32 --host=mingw32 --target=avr --enable-languages=c,c++
Thread model: single
gcc version 3.4.1

command line:
avr-gcc -gdwarf-2 anycode.c  -o anyobject.elf

No matter how I tweak the command line parameters to avr-gcc I am unable to make
it output dwarf2 callstack information (.debug_frame). I have confirmed that
this is a missing feature for the AVR port.

-- 
   Summary: avr-gcc does not output a dwarf2 .debug_frame section
   Product: gcc
   Version: 3.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsandnes at atmel dot com
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: 386
GCC target triplet: AVR


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17994


[Bug debug/17993] Error in dwarf2 debug output of bitfield members

2004-10-14 Thread tsandnes at atmel dot com

--- Additional Comments From tsandnes at atmel dot com  2004-10-14 08:24 ---
This has been discussed on the gcc mailinglist:
http://gcc.gnu.org/ml/gcc/2004-05/msg00186.html

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17993