Re: [Simulavr-devel] asm and --gstabs

[scott]

"Theodore A. Roth" wrote:
> 
> I think I see where our problem is. Here's my theory:
> 
> Scott is taking a single asm file, assembling into an object file, then
> linking the object file into his rom image. The linker will relocate the
> asm object file and the addresses will be filled in.
> 
> In my case, I have a single asm file which is the entire rom image. No
> linking is done, thus my symbol table in the object file (rom image) has
> not been relocated and all the addresses are zero.
> 
> Now to test my theory:
> 
> Scott, can you do this:
>   avr-objdump --stabs os_cpu_a.o
>   avr-objdump --stabs rom.elf
> If I'm right, you should have n_value's of 0 for SLINE's in the os_cpu_a.o
> dump and actual addresses for the relocated os_cpu_a.o part of rom.elf.
That's exactly what I am seeing:
os_cpu_a.o (extract):
avr/src/ucosii/ATmega128-ucos/os_cpu_a.o:     file format elf32-avr
Contents of .stab section:
Symnum n_type n_othr n_desc n_value  n_strx String

-1     HdrSym 0      295    0000003b 1     
0      SO     0      0      00000000 17     /tmp/ccadwkVf.s
1      SOL    0      0      00000000 33     avr/src/ucosii/os_cpu_a.S
2      SLINE  0      89     00000000 0      
3      SLINE  0      90     00000000 0      
4      SLINE  0      91     00000000 0      
5      SLINE  0      92     00000000 0      
6      SLINE  0      94     00000000 0      
7      SLINE  0      95     00000000 0      
8      SLINE  0      96     00000000 0      
9      SLINE  0      97     00000000 0      


And from the final linked image (rom.elf):
7441   SOL    0      0      0000d60c 85398  avr/src/ucosii/os_cpu_a.S
7442   SLINE  0      89     0000d60c 0      
7443   SLINE  0      90     0000d60e 0      
7444   SLINE  0      91     0000d612 0      
7445   SLINE  0      92     0000d614 0      
7446   SLINE  0      94     0000d618 0      
7447   SLINE  0      95     0000d61c 0      
7448   SLINE  0      96     0000d620 0      
7449   SLINE  0      97     0000d622 0      



> How do tell the link not to link to a crt file and only build the rom
> image with symbol table relocated? I think I've seen this question posed
> on the avr-gcc-list, but have never seen an answer.

If you were to produce individual .o files (for each source file) and then call
the linker (avr-ld) directly this should work (assuming that nothing in your
code is dependant on symbols in the crt file). It is gcc who decides that you
need startup code. If you don't specify the startup code specifically, it will
tack an entry onto the command that it passes to avr-ld telling it to link in
the version in the library.

Alternatively, if all else fails, if you specify the startup code on the link
line (even if you use gcc as the linker) as the last entry (ie file1.o file2.o
gcrt1.o), it will link with the startup code at the end. This of course will not
run but you can then prune off the "offending appendage" (with a tool like
srecord). 

Cheers,

Scott