LSS Files are being corrupted AS6.1 toolchain 3.4.2.876

Go To Last Post
34 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

this is from the latest AVR Studio 6.1 Tool Chain

Installed Packages: Atmel AVR (8 bit) GNU Toolchain - 3.4.2.876
AVR Toolchain 8 Bit
Version: AVR8_Toolchain_Version:3.4.2.876 GCC_VERSION:4.7.2

the LSS listing file is corrupted

im building demo LUFA projects and noticed
that functions that are NOT in the actual complied code are showing up in the lss file

this is a CDC demo, no audio what so ever

Disassembly of section .text:

00000000 <__vectors>:
#define  __INCLUDE_FROM_AUDIO_DRIVER
#define  __INCLUDE_FROM_AUDIO_DEVICE_C
#include "AudioClassDevice.h"

void Audio_Device_ProcessControlRequest(USB_ClassInfo_Audio_Device_t* const AudioInterfaceInfo)
{
   0: 7f c0        rjmp .+254     ; 0x100 <__ctors_end>

 

audio class stuff all over the lss

its clearly not the code...

 

 

like in main...

 

  case AUDIO_REQ_GetCurrent:
  case AUDIO_REQ_GetMinimum:
  case AUDIO_REQ_GetMaximum:
  case AUDIO_REQ_GetResolution:
   if ((USB_ControlRequest.bmRequestType & CONTROL_REQTYPE_RECIPIENT) == REQREC_ENDPOINT)
 1fc: 91 e0        ldi r25, 0x01 ; 1
 1fe: af d0        rcall .+350     ; 0x35e 
 200: 23 d3        rcall .+1606    ; 0x848 
 202: f8 cf        rjmp .-16      ; 0x1f4 

 

now dean thinks its related to

-ffunction-sections and --gc-sections compiler switches

here is a quote from dean:

Quote:

I've noticed that too, although it's gotten much, much worse in the new toolchain that ships in AS6.1 (based on GCC 4.7). The issue is the -ffunction-sections and --gc-sections compiler switches; these allow the compiler and linker to discard unused functions (which is absolutely required in a not-traditionally-structured library like LUFA). Without these options, compiling a LUFA application would unconditionally leave all compiled functions from the entire library in every application, which would be enormous.

However, when a section (containing a single compiled function) is discarded by the linker, the symbol start location for the function in the binary is set to an address of 0x00000000. That causes the ELF parser to dump out a bunch of random discarded code when it tries to disassemble the ELF and produce a mixed LSS listing file, since it thinks the reset vector code at address 0x00000000 is part of some unused functions. I'm not sure how previous versions of GCC handled this, but something in the newer release causes it to display more unwanted source code at the reset vector than older versions did.

need to get this to the GCC/GNU tool chain developers...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This, and other issues with gc-sections, are as old as the -gc-sections option itself.

It's not just an AVR thing. See for example
http://lists.gnu.org/archive/html/bug-binutils/2012-03/msg00021.html

I doubt your complaint to the tool chain developers will be received with much sympathy, because the 'sections' paradigm was not meant to be used as a substitute for proper library construction.

Fortunately in this case, it looks like mostly a 'cosmetic' issue.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does it use -relax? That is another famous way to get disassembly that is out of step with the source. Every place a JMP or CALL is replaced with RJMP or RCALL the problem gets worse and worse.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Does it use -relax? That is another famous way to get disassembly that is out of step with the source. Every place a JMP or CALL is replaced with RJMP or RCALL the problem gets worse and worse.

That has actually been fixed in the released toolchain (3.4.2), and is on the way to getting upstreamed to binutils mainline. Did you notice this happening in the latest toolchain?

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I thought I was still seeing it with my bootloader source but I'll check again when I have access to my PC.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Senthil,

As far as I can see the relax (in 6.1B) still breaks this:

__attribute__((noinline)) void bar(void) {
	PORTC = 0xAA;
}

__attribute__((noinline)) void foo(void) {
	PORTB = 0x55;
	bar();
}

int main (void){
	foo();
}

Without -Wl,-relax I get:

0000006c :
#include 
#include 
#include 

__attribute__((noinline)) void bar(void) {
	PORTC = 0xAA;
  6c:	8a ea       	ldi	r24, 0xAA	; 170
  6e:	85 bb       	out	0x15, r24	; 21
  70:	08 95       	ret

00000072 :
}

__attribute__((noinline)) void foo(void) {
	PORTB = 0x55;
  72:	85 e5       	ldi	r24, 0x55	; 85
  74:	88 bb       	out	0x18, r24	; 24
	bar();
  76:	0e 94 36 00 	call	0x6c	; 0x6c 
  7a:	08 95       	ret

0000007c 
: } int main (void){ foo(); 7c: 0e 94 39 00 call 0x72 ; 0x72 } 80: 80 e0 ldi r24, 0x00 ; 0 82: 90 e0 ldi r25, 0x00 ; 0 84: 08 95 ret

I think you'd agree that after the main: label at 0000007c the annotation is correct:

	foo();
  7c:	0e 94 39 00 	call	0x72	; 0x72 
}

The C source showing the call "foo();" is immediately followed by the actual call that implements this (building for mega16 by the way). Now I enable -Wl,-relax and get:

00000066 :
#include 
#include 
#include 

__attribute__((noinline)) void bar(void) {
	PORTC = 0xAA;
  66:	8a ea       	ldi	r24, 0xAA	; 170
  68:	85 bb       	out	0x15, r24	; 21
  6a:	08 95       	ret

0000006c :
}

__attribute__((noinline)) void foo(void) {
	PORTB = 0x55;
  6c:	85 e5       	ldi	r24, 0x55	; 85
  6e:	88 bb       	out	0x18, r24	; 24
	bar();
  70:	fa cf       	rjmp	.-12     	; 0x66 

00000072 
: 72: fc df rcall .-8 ; 0x6c 74: 80 e0 ldi r24, 0x00 ; 0 } int main (void){ foo(); } 76: 90 e0 ldi r25, 0x00 ; 0 78: 08 95 ret

the point where main() calls foo(); is now:

00000072 
: 72: fc df rcall .-8 ; 0x6c

yet the annotation for this does not occur until several lines later at:

int main (void){
	foo();
}
  76:	90 e0       	ldi	r25, 0x00	; 0

where that is half way through the lod of r25:r24 with 0x0000 for the return from main().

So, as far as I can see, this is still broken.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah, I should have mentioned this in my original post, but you should compile with -mrelax passed to avr-gcc, in addition to -Wl,-relax when linking.

The fix for the issue required the assembler to know if relaxation is turned on - it basically adjusts stuff so that the code size reduction during linker relaxation doesn't mess up line number mapping. Passing -mrelax passes the relax flag to the assembler (and the linker, if you're doing both assembling/linking).

I should add this to the bug description in the release notes I guess. Can you try with -mrelax and see if that works?

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah that works. But I wouldn't rely on people reading the release notes. The best bet would be in the Project options under compiler-optimization to have a single box that passes "-Wl,-relax -mrelax" when ticked as most people trying to relax are going to use one or the other but not both.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't think you need another -Wl,--relax if you've already got -mrelax.
-mrelax automagically makes the compiler activate the linker's --relax
option.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah you are quite right.

(rather sadly I used -Wl,-relax rather than -mrelax but I maybe in a minority of one if you are lucky!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Holy moley, that actually works! Finally, working LSS disassembly. No more do I have to scrounging around to find the actual matching instructions for a section of code.

I'll update the LUFA build system to fix this now.

- Dean :twisted:

PS: I'm in the minority with Cliff; I still use -Wl,--relax even if I'm also passing -mrelax to the compiler...

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, that makes me a little less nervous now :) - I fixed this bug, following the approach taken by another target (xtensa), and I had to change all three (gcc, gas and ld) to get it to work.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Senthil,

Jörg's point was that if the user uses "avr-gcc -mrelax" then in that case -relax is passed to all components that need to know but if -Wl,-relax is used (as is common as both Dean and I tried to do it that way) then the option is only passed to the linker.

So somehow you need to educate users of AS6 to only use -mrelax when they want relaxation. Perhaps the easiest way to do that is to list a tick box under "Optimization" because if there's a box there and it apparently always works (because it leads to -mrelax being used) then users won't be tempted to just try -Wl,-relax.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> Perhaps the easiest way to do that is to list a tick box under "Optimization"

And, please, this box ought to be activated by default for any device with more
than 128 KiB of flash. Otherwise, users of these devices will be left with
defective function pointers once their application exceeds 128 KiB.

(Yes, @Jan [Waclawek], I know the relaxation still has bugs. But using it then
is still better than having stray pointers anyway.)

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is it dangerous to enable relaxations in the linker explicitly? If I test the WTK Example project from ASF on the XMEGA-A3BU Xplained, it now breaks using the default configuration on the latest compiler from Atmel Studio 6.1 beta. Removing all the relax commands from the toolchain settings except for a single -mrelax to the compiler fixes it. Is this a deeper issue, or is adding -mrelax to the linker invalid?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, code should still work fine if relaxation is enabled only for the linker - only line number debug info could be potentially broken.

Does "it now breaks" mean wrong code, or a crashing compiler/linker?

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It compiles, but the code doesn't run; it looks like there is a bunch of random(ish) memory corruption. Do you have a MXT143E Xplained kit for testing?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just got back home. I don't think we have that kit.

Can you email me the project so I can take a look? Do you have a rough idea of where in the code the memory corruption could be coming from?

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's the "Paint Demo" I wrote inside the latest ASF - the corruption seems to be present when building any of the MXT143E Xplained demos.

I just did a bit more debugging; it seems the const tables we are using in RAM (not PROGMEM) aren't being loaded correctly. If you open that example, place a watch on the variable "pallet_colors" and start it (use a bare A3-BU Xplained kit - even without a screen you should be able to see this). The values in the table are all 0xFFFF on startup when they should be various RGB color values.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's the problem table:

const gfx_color_t pallet_colors[] = {
	0,           /**< First entry is for multi-color mode */
	GFX_COLOR_WHITE,
	GFX_COLOR_BLACK,
	GFX_COLOR_RED,
	GFX_COLOR_GREEN,
	GFX_COLOR_BLUE,
	GFX_COLOR_MAGENTA,
	GFX_COLOR_YELLOW,
	GFX_COLOR_CYAN,
	0,           /**< Last entry is for clear function */
};

The gfx_color_t is a typedef to uint16_t, and the GFX_COLOR_* macros are just constants. If I remove the const from the table the demo works, but if I leave it const it is initialized to all 0xFFFF on startup.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried inspecting the array after breaking into main (on simulator), and the array did have the right values. Tried this with ASF 3.7.0 and mXT143E Xplained Paint Demo - XMEGA-A3BU Xplained - ATxmega256A3BU on the simulator with no changes made to the build settings (-mrelax on both compiler and linker, and an additional -Wl,--relax on linker).

Can you send me the build output, ELF file and the map file for the wrong code?

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've sent them via internal email to you - I have some highly sensitive internal packages installed and don't want to accidentally leak anything.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Having just banged my head against this problem for some hours before finding this thread, can I as for clarification?
If I add
-mrelax
to the compiler optimization, the LSS files seem to behave, but what are the unintended/unwelcome consequences of this, if any?

John

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

to the compiler optimization, the LSS files seem to behave, but what are the unintended/unwelcome consequences of this, if any?

None, passing it to the compiler makes it work as both the compiler and the linker and informed of the setting. Passing it to the linker (only) causes unhappy LSS files.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm guessing you are using a legacy project? With the latest 6.1.1 if you create a new project it seems the "global" relax flag is set by default. I'm not sure if that's a good thing or a bad thing but at least it means that in future you are unlikely to be bitten by this.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If by "legacy" you mean a project created with an earlier version of AS, then yes.

Thanks for the clarification.

John

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Relax, John, just relax. At compile time especially. Then, at link time, just relax.

"Doctor, doctor--I keep dreaming about teepees and wigwams. What could be the problem?!?"

"Obviously, you are too tense. That will be $20."

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
None, passing it [-mrelax] to the compiler makes it work as both the compiler and the linker and informed of the setting.
Actually, the compiler just passes through this option as --relax to the linker. Beside that passing, the compiler is completely agnostic about -mrelax and does not use the switch in any other way.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Actually, the compiler just passes through this option as --relax to the linker. Beside that passing, the compiler is completely agnostic about -mrelax and does not use the switch in any other way.

Wasn't there a patch in the compiler to fix the listings? I get incorrect LSS file output if I only pass -Wl,--relax to the linker, but correct output with -mrelax.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The only place in the compiler sources is LINK_SPEC in avr.h. Or am I missing something?

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVRTC-610: "Debug symbol synchronization issue versus assembly code ".

diff -Naurp gcc/config/avr/avr.h gcc/config/avr/avr.h
--- gcc/config/avr/avr.h
+++ gcc/config/avr/avr.h
@@ -627,7 +627,8 @@ extern const char *avr_device_to_sp8 (in
 #define ASM_SPEC "%{mmcu=avr25:-mmcu=avr2;mmcu=avr35:-mmcu=avr3;mmcu=avr31:-mmcu=avr3;mmcu=avr51:-mmcu=avr5;\
 mmcu=*:-mmcu=%*} \
 %{mmcu=*:%{!mmcu=avr2:%{!mmcu=at90s8515:%{!mmcu=avr31:%{!mmcu=atmega103:\
--mno-skip-bug}}}}}"
+-mno-skip-bug}}}}} \
+%{mrelax:-mlink-relax}"

 #define LINK_SPEC "\
 %{mrelax:--relax\

Couples with some patches to binutils 2.23 according to the entry.

- Dean :twisted:

(Looking into my crystal ball to predict the future: something about Atmel patches not being canonical source even though they are publicly available...)

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The change to ASM_SPEC is not upstream and Atmel-specific.

abcminiuser wrote:
something about Atmel patches not being canonical source even though they are publicly available...)
But that's 100% up to Atmel to make it "canonical" or not.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Relax, John, just relax. At compile time especially. Then, at link time, just relax.

"Doctor, doctor--I keep dreaming about teepees and wigwams. What could be the problem?!?"

"Obviously, you are too tense. That will be $20."

Thanks Lee, I feel better now.

In real life, does anyone ever address their physician in this duplicated manner? I shall try it the next time I visit my GP and see if he notices.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

In real life, does anyone ever address their physician in this duplicated manner?

"In real life", at my last doctor's visit he needed to leave the examining room and wanted me to remain. He tells me "Sit! Stay!" as if addressing a dog. (joking)

My response: "Physician, heal thyself." [pun on "heel"]

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.