This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

H8300-elf-as DWARF problem preliminary analysis


Hi,
	This is in reference to my previous posting:
	http://sources.redhat.com/ml/binutils/2002-08/msg00050.html

	After further analysis I have following observations:
	1.) Though the length on .debug_length section
	     is known at compile time still a relocation entry
	     is generated. However other targets 	(sh-elf and 
		i386 at least I have seen) no relocation entry
		is generated for these values. Is this some
		special treatment for h8300-elf target?

	2.) The relocation entry generated for length (and prologue
	      length) is not correct.
		e.g. for this following code (.s)
		...
		        .section        .debug_line
				        .4byte  .LELT0-.LSLT0   ;# Length of
Source Line Info
				.LSLT0:
				        .2byte  0x2     ;# DWARF Version
				        .4byte  .LELTP0-.LSLT0  ;# Prolog
Length
				        ;.4byte .LELTP0-.LASLTP0        ;#
Prolog Length
				.LASLTP0:
				        .byte   0x1     ;# Minimum
Instruction Length
				        .byte   0x1     ;# Default
is_stmt_start flag
				        .byte   0xf6    ;# Line Base Value
(Special Opcodes)
				        .byte   0xf5    ;# Line Range Value
(Special Opcodes)
				        .byte   0xa     ;# Special Opcode
Base
				        .byte   0x0     ;# opcode: 0x1 has 0
args
				        .byte   0x1     ;# opcode: 0x2 has 1
args
				        .byte   0x1     ;# opcode: 0x3 has 1
args
				        .byte   0x1     ;# opcode: 0x4 has 1
args
				        .byte   0x1     ;# opcode: 0x5 has 1
args
				        .byte   0x0     ;# opcode: 0x6 has 0
args
				        .byte   0x0     ;# opcode: 0x7 has 0
args
				        .byte   0x0     ;# opcode: 0x8 has 0
args
				        .byte   0x1     ;# opcode: 0x9 has 1
args
				        .byte   0x0     ;# End directory
table
				        .ascii "test.c\0"       ;# File
Entry: 0x1
				        .uleb128 0x0
				        .uleb128 0x0
				        .uleb128 0x0
				        .byte   0x0     ;# End file name
table
				.LELTP0:
				        .byte   0x0     ;#
DW_LNE_set_address
				        .uleb128 0x5
			....
		
		The relocation entries for debug_line are
		...
		   Relocation section '.rela.debug_line' at offset 0x854
contains 6 entries:
		 	Offset     Info    Type            Symbol's Value
Symbol's Name          Addend
			00000000  00001801 R_H8_DIR32            00000046
.LELT0                    + 0
			00000006  00001901 R_H8_DIR32            00000024
.LELTP0                   + 0
		...

		Please note that size of the whole .debug_line section is
0x46 in the
		.o file. Hence the length of debug_line section should be
0x42.
		Also the prologue length is should be 0x1a  (and not 0x24).
		The assembler is directly putting the "high_label" (when
		expression is high_label - low_label) in relocation entry.
		The code in tc_gen_reloc() in tc-h8300.c justifies this
		observation. It does not use fixp->fx_subsy at all. Due
		to this, fixp->fx_addsy is propagated as relocation value.  
		
		Solution
		The work around of this problem could be to fix 
		tc-h8300.c to take care of value of fixp->fx_subsy 
		too. However the problem would be completely 
		solved only when the absolute value is stored 
		instead of relocation entry (as it is done for
		other targets).
	
		Please let me know your thoughts about the problem 
		and the fix.
Thanks and Regards.
Nitin.
	
		


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]