No C code in .lss file

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

First I'm not sure if this should be under studio related stuff , but since the .lss is made by the compiler I placed it here (feel free to move).

 

For a on going project 5+ years I use studio 4 with winAVR 2010. 

When it make a .lss file the C code is included (moved around etc. by the optimizer )

 

Now I wanted to see the output from the studio 7 with the build in 4.9.2 GCC compiler.

As a test I made a new project (mega 324 but don't think it matter) as studio 7 default make a project , and then took the old code.

It compiles fine, (can't test if it works). But the .lss have no C information.

 

When I look a the dissembled code when I debug mode, it has the C code. I have looked around but can't find a check for that.

 

Can anyone help ?

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

nobody know ?

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

The links to the source get put into the ELF when -g is used. In fact more specifically it would usually be the -gdwarf-2 variant of the command. That puts .debug_XXX sections into the ELF and some of those list files and line numbers. Later tools like "avr-objdump -S" use that same info to go and read the files/lines involved and prettify their output.

 

Note however that it is not actual lines of C code embedded in the ELF. It is just references to files and line numbers. So what can happen is that if you build on one machine then take just the ELF to another and then use objdump on that it won't be able to annotate as it won't be able to "see" the source files.

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

PS just noticed the comment about source in the debugger. Atmel have their own ELF file reader that does the source annotation. That does seem to suggest the -g stuff is there. So the fault would appear to be either in objdump not reading it OK or not "seeing" the source files that are referred to in there.

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

Did you use the objdump from the same binary package as the gcc you used?

 

How exactly did you invoke it?

 

Care to provide a sample .elf (from some trivial simple .c program) which exhibits the problem?

 

JW

Last Edited: Thu. Feb 2, 2017 - 12:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First I can't check it at the moment, I'm where I use studio 4 (and it's not my setup).

 

I have a new studio 7 download (1-2 month ago or so), and have not changed anything (I think/hope) I made a normal 324 project, and in the C file it generate by it self I just pasted a known good 324 C file (one used on studio 4), so there are no old project info. The only thing I have changed is -O1  to -O2 or -Os (but that mean anything about this)

 

It compiles fine and I can simulate the output code and that works fine, and if I show dissemble code it works and here the C code show fine. 

 

But my problem is that the .lss file have no source code info at all !

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

ok I looked at the output from the 2010 winavr , and it has this :

 

avr-objdump -h -S BASIC_begge.elf > BASIC_begge.lss

 

(don't be confused BASIC is a product name)

 

so does that mean that  -h  or  -S do the trick ? 

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

ok I could not find the meaning of -h and -S 

So I started to change the studio 4 make file and when I removed both :) I got this :

 At least one of the following switches must be given:
  -a, --archive-headers    Display archive header information
  -f, --file-headers       Display the contents of the overall file header
  -p, --private-headers    Display object format specific file header contents
  -h, --[section-]headers  Display the contents of the section headers
  -x, --all-headers        Display the contents of all headers
  -d, --disassemble        Display assembler contents of executable sections
  -D, --disassemble-all    Display assembler contents of all sections
  -S, --source             Intermix source code with disassembly
  -s, --full-contents      Display the full contents of all sections requested
  -g, --debugging          Display debug information in object file
  -e, --debugging-tags     Display debug information using ctags style
  -G, --stabs              Display (in raw form) any STABS info in the file
  -W, --dwarf              Display DWARF info in the file
  -t, --syms               Display the contents of the symbol table(s)
  -T, --dynamic-syms       Display the contents of the dynamic symbol table
  -r, --reloc              Display the relocation entries in the file
  -R, --dynamic-reloc      Display the dynamic relocation entries in the file
  @<file>                  Read options from <file>
  -v, --version            Display this program's version number
  -i, --info               List object formats and architectures supported
  -H, --help               Display this information

 

so it's  -S   that are missing.

I guess a default studio 7 project don't have it  (I don't think it's a wrong path when it's all default) 

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

The way to create an  LSS has always been "avr-objdump -S proj.elf > proj.lss". I am certain that's what AS7 uses just as AS4 did before it. Are you saying As7 has some other command it uses for creating .lss? The only one it could really be is a -d rather than -S but if it was doing that I'm sure someone else would have noticed by now.

 

Was this project an "import" or something?

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

So is this basically "solved" now? May I return to do some merital work? ;-)

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

 

Was this project an "import" or something?

 

still no it's a new studio 7 project (even its own name application7 or something like that ), and in the C file it generated , I pasted a legal C code, (to make sure that no old info was inclused).

 

But I will be home in about 4 hours then I can check it.

 

I'm just checking if it's time to take the step from 4 to 7, (or rather GCC 4.3.? or whatever winAVR2010 was based on and up to 4.9.2

they both have strong and weak sides.)

 

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

OK now I have checked.

First with this program 

PORTA=PINB;

And that works fine.

Then again I pasted the same old C program, and again no source code, but that is actually not true at the very top there actually is 5 lines of c code ! (and it has nothing to do with the first code!).

So there are something it don't like so are any of these things a problem in the studio 7 setup :

 

#include <util/atomic.h> 

extern signed int __data_load_end;

 

#include <ctype.h>
#include <stdint.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <avr/io.h>
#include <avr/pgmspace.h>
#include <avr/interrupt.h>

  ATOMIC_BLOCK(ATOMIC_RESTORESTATE){

 

 

 

 

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

I guess I'd need to see the entire program.  What is the fragment posted above?  I also have a "vanilla" Studio7-produced test program that I can drop code into and see what happens.

 

 

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.

Last Edited: Thu. Feb 2, 2017 - 08:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can't give it. (its a commercial program) 

 

But from a C perspective there are nothing fancy, that's why I cut and pasted those thing that could be incompatible. 

 

And again the disassemble in the studio 7 debug show it correct that is what really baffle me.  

And just for now I live with that.  

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

Just happened to notice that when you compile your program in a Release configuration vs. a Debug configuration, the .lss file contains no C code.  If you attempt to debug this version of the .elf file, the disassembly window opens.  The debugger cannot associate the code you are debugging with the original .c files.  

M. Richmond

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

Time to re-read the thread, sparrow2. Take note of clawsons post #3 about the -g switch for a start. The post #15 by mrichmond just above is likely your problem.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

it's an old thread! (but good info).

 

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

Atmel are mad. Simple as that. There is no reason on earth why Release should be any different to Debug in terms of -g for AVR code because unlike a PC where the debug forms part of the binary in AVR the -g stuff only makes it as far as the ELF so it makes as much sense for it to be there for Release as Debug. In fact, apart from maybe a different optimisation level there's very little motive for doing the Debug/Release thing in AS7