ELF/DWARF problem with array/structure in .data section

Log in or register to post comments
Go To Last Post
10 posts / 0 new
Author
Message
donblake
donblake's picture
Level: Posting Freak
Joined: Sat. Jan 3, 2004
Posts: 1554 View posts
Location: Binghamton, NY, USA
#1
Posted by donblake: Sun. Sep 19, 2004 - 10:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am having a problem with a WINAVR 20040720 generated DWARF-2 .elf file using AVR Studio 4.10 build 356. I’ve stripped my ATMEG8 program down to a “bare” minimum that still exhibits the problem:

#include 
#include 
#include 

typedef struct {
  uint16_t strikeValue;
  uint8_t  displayValue;
  uint8_t  highWaterValue;
} lookupTableEntry_t;

volatile uint8_t  timerOverflow;
volatile uint8_t  led9OnCount;
volatile uint16_t strikeCount;

lookupTableEntry_t lookupTable[ ] = {
  { 1, 2, 3 },
  { 4, 5, 6 }
};

SIGNAL( SIG_INTERRUPT0 )
{
  if ( strikeCount < 0x2800 ) strikeCount++;
  led9OnCount = 2;
}

SIGNAL( SIG_OVERFLOW1 )
{
  TCNT1 = -200;
  timerOverflow = 0xFF;
}

int main( void )
{
  return 1;
}

The AVR Simulator does not load the lookupTable array/structure correctly. When I display Data Memory, it shows the following:

Quote:
000060 01 00 02 03 04 00 32 00 00 00 00 00 FF FF FF FF

The highlighted bytes are incorrect.

It works okay if I build an Extended COFF module. Data Memory is displayed as follows:

Quote:
000060 01 00 02 03 04 00 05 06 00 00 00 00 FF FF FF FF

Note: The updated DLL files from parserdll.zip don’t make any difference.

Don

Tags:

Tools, Atmel Studio (AVR-related)
Top
EW
EW's picture
Level: Raving Lunatic
Joined: Thu. Mar 1, 2001
Posts: 4914 View posts
Location: Rocky Mountains
Posted by EW: Mon. Sep 20, 2004 - 03:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

donblake wrote:
I am having a problem with a WINAVR 20040720 generated DWARF-2 .elf file using AVR Studio 4.10 build 356. I’ve stripped my ATMEG8 program down to a “bare” minimum that still exhibits the problem:

#include 
#include 
#include 

typedef struct {
  uint16_t strikeValue;
  uint8_t  displayValue;
  uint8_t  highWaterValue;
} lookupTableEntry_t;

volatile uint8_t  timerOverflow;
volatile uint8_t  led9OnCount;
volatile uint16_t strikeCount;

lookupTableEntry_t lookupTable[ ] = {
  { 1, 2, 3 },
  { 4, 5, 6 }
};

SIGNAL( SIG_INTERRUPT0 )
{
  if ( strikeCount < 0x2800 ) strikeCount++;
  led9OnCount = 2;
}

SIGNAL( SIG_OVERFLOW1 )
{
  TCNT1 = -200;
  timerOverflow = 0xFF;
}

int main( void )
{
  return 1;
}

The AVR Simulator does not load the lookupTable array/structure correctly. When I display Data Memory, it shows the following:

Quote:
000060 01 00 02 03 04 00 32 00 00 00 00 00 FF FF FF FF

The highlighted bytes are incorrect.

It works okay if I build an Extended COFF module. Data Memory is displayed as follows:

Quote:
000060 01 00 02 03 04 00 05 06 00 00 00 00 FF FF FF FF

Note: The updated DLL files from parserdll.zip don’t make any difference.

Does the generated assembly look ok when building for ELF/DWARF2?

I want to make sure that this isn't a compiler issue. Thanks
Eric

Eric Weddington
www.linkedin.com/in/ericweddington/

Top
JerzySzczesiul
JerzySzczesiul's picture
Level: Hangaround
Joined: Thu. Nov 14, 2002
Posts: 117 View posts
Posted by JerzySzczesiul: Mon. Sep 20, 2004 - 06:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EW wrote:

I want to make sure that this isn't a compiler issue. Thanks
Eric

Hi Eric.

Strange. I've simply copied donblake's snippet and everything is OK.
AvrStudio 4.10/b.356;
toolset: gcc-3.4.2/binutils-2.15/libc-1.0.4 ,mingw32/i686
Windows XP pro SP1

Best regards
Jurek S.

Top
donblake
donblake's picture
Level: Posting Freak
Joined: Sat. Jan 3, 2004
Posts: 1554 View posts
Location: Binghamton, NY, USA
Posted by donblake: Mon. Sep 20, 2004 - 06:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EW wrote:
Does the generated assembly look ok when building for ELF/DWARF2?

Eric, yes, the assembly looks okay:

  19               		.data
  22               	lookupTable:
  23 0000 0100      		.word	1
  24 0002 02        		.byte	2
  25 0003 03        		.byte	3
  26 0004 0400      		.word	4
  27 0006 05        		.byte	5
  28 0007 06        		.byte	6

JerzySzczesiul wrote:
Strange. I've simply copied donblake's snippet and everything is OK.

Yes, that is strange. I see this problem on two different computers - one with Windows 98 SE and the other with Windows 2000 Professional. JerzySzczesiul, did you build a dwarf-2 module? I don't see this problem when I build a stabs module then create an extended COFF file.

Don

Top
donblake
donblake's picture
Level: Posting Freak
Joined: Sat. Jan 3, 2004
Posts: 1554 View posts
Location: Binghamton, NY, USA
Posted by donblake: Mon. Sep 20, 2004 - 07:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh, by the way, I used avr-objdump to display the contents of the .elf file and the .data section looks okay:

Contents of section .data:
 800060 01000203 04000506                    ........

Don

Top
JerzySzczesiul
JerzySzczesiul's picture
Level: Hangaround
Joined: Thu. Nov 14, 2002
Posts: 117 View posts
Posted by JerzySzczesiul: Mon. Sep 20, 2004 - 07:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

donblake wrote:

JerzySzczesiul, did you build a dwarf-2 module? I don't see this problem when I build a stabs module then create an extended COFF file.
Don

Yes, dwarf-2.
I've got valid values both in data memory and watch AvrStudio windows.

Best regards
Jurek S.

Top
donblake
donblake's picture
Level: Posting Freak
Joined: Sat. Jan 3, 2004
Posts: 1554 View posts
Location: Binghamton, NY, USA
Posted by donblake: Mon. Sep 20, 2004 - 09:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JerzySzczesiul wrote:
Yes, dwarf-2.
I've got valid values both in data memory and watch AvrStudio windows.

Jurek S., thanks for trying to re-create the problem. I've discovered that I had OPT = 0 set in my makefile. When I use OPT = s I don't see the problem. I've been using OPT = 0 because it makes debugging easier.

I don't think it's really OPT = 0 that's causing the problem. What I've discovered is almost any little change will make the problem go away or come back. I expect that OPT = 0 is causing the .elf file to be different enough that the AVR Studio parser doesn't handle it correctly.

Don

Top
EW
EW's picture
Level: Raving Lunatic
Joined: Thu. Mar 1, 2001
Posts: 4914 View posts
Location: Rocky Mountains
Posted by EW: Mon. Sep 20, 2004 - 09:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Be sure to report this to Atmel so they can improve AVR Studio.

Eric Weddington
www.linkedin.com/in/ericweddington/

Top
donblake
donblake's picture
Level: Posting Freak
Joined: Sat. Jan 3, 2004
Posts: 1554 View posts
Location: Binghamton, NY, USA
Posted by donblake: Mon. Sep 20, 2004 - 09:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EW wrote:
Be sure to report this to Atmel so they can improve AVR Studio.

I just did. Thanks Eric.

Don

Top
donblake
donblake's picture
Level: Posting Freak
Joined: Sat. Jan 3, 2004
Posts: 1554 View posts
Location: Binghamton, NY, USA
Posted by donblake: Thu. Sep 30, 2004 - 11:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I received a fix from Atmel. The attached .zip file contains an updated libelfdwarfparser.dll. I'm an also using libdwarf.dll and AvrParserElfDwarf.dll from parserdlls.zip (https://www.avrfreaks.net/phpBB2/viewtopic.php?t=22802).

All of these .dll files replace those in \Atmel\AVR Tools\Parsers.

Don

Attachment(s): 

Package icon libelfdwarfparser.zip
Top