about the C code insertion in lss file

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

hi,

I have noticed that sometime the compiled lss file include the original C code, but sometimes some part of it (ISR for example) doesn't include any C code. Is there any setting to config it so that it insert all the C codes into lss?

I'm doing some timing estimation for my code, the lss file is the only one I used to manually count clks.

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

It might be that you have optimizations turned on and the compiler sees that the code you have won't be doing anything lasting, ie you do a load of work with locals in the ISR but never assign a result that can be used elsewhere. To fix it you could turn optimizations off, but much of the code generated will be unecessary and waste space/cycles, or you could assign the result to a volatile global.

Edward

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

aha, thanks, Edward, I will check this

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

It might help to understand where the .LSS file comes from. When you build a GCC program the following occurs:

1) .c files are compiled to .o (obect) files
2) .S files are assembled to .o files
3) the linker pulls together all the .o files together with some library code from .a (archive) libraries, it fixes up any links between the files then it outputs all this to a .elf file
4) inside the .elf file is all the "used" binary code of the program and, for it, there is Dwarf2 debugging information which basically connects each opcode of the program to a line in a .c file that generated it (there wont be binary to source links for code from .S files though)
5) avr-objcopy strips just the binary part of the program from the Elf/Dwarf2 file then converts it from binary to Intel hex and writes the output .hex file
6) it does the same to pull out any default EEPROM data and writes it to an Intel hex .eep file
7) avr-objdump is used to extract from the .elf file an interleaved dump of the generated opcodes and the .c source that generated it in human readable form so that you, the end user, can see exactly what went into thte program

Clearly (7) is the key step here as far as your question is concerned. The way you change what appears in the file is by chaging what goes into and happens at steps (1) and (2)

Like Edward says, if some ISR code is no present in the LSS then that's because it was never used in the compile/link (or you wrote it in a .S file) and this could be because the compiler recoginsed that it wasn't doing anything useful and optimised it out.

One key thing to look for in the .lss is the <__vectors> section showing the actual vector jumps that have been generated. Is there a jump to something other than <__bad_interrupt> for the ISR that you think there is "missing" code for? If there is a jump then look at it's destination address and then scan through the .lss for any code at that address. It may be listed only in assembler.

Cliff

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

ok, thanks, Cliff