I use WinARM from Yagarto (gcc 4.1.1)
I tried with this sample file:
int main(void)
{
int a;
a = 3;
return 0;
}
compile with:
arm-elf-gcc -c -mcpu=arm7tdmi -I. -g3 -DROM_RUN -Wall -Wcast-align
-Wcast-qual -Wimplicit -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wunused -Wa,-adhlns=dummy.lst -I./include -MD
-MP -MF .dep/dummy.o.d -Wstrict-prototypes -Wmissing-declarations
-Wmissing-prototypes -std=gnu99 dummy.c -o dummy.o
and dummy.lst is:
1 .file "dummy.c"
11 .Ltext0:
243 .align 2
244 .global main
246 main:
247 .LFB2:
1:dummy.c **** int main(void)
2:dummy.c **** {
248 e_needed = 1, uses_anonymous_args = 0
249 mov ip, sp
250 .LCFI0:
251 0000 0DC0A0E1 stmfd sp!, {fp, ip, lr, pc}
252 .LCFI1:
253 0004 00D82DE9 sub fp, ip, #4
254 .LCFI2:
255 0008 04B04CE2 sub sp, sp, #4
256 .LCFI3:
257 000c 04D04DE2 .loc 1 4 0
258 mov r3, #3
3:dummy.c **** int a;
4:dummy.c **** a = 3;
259 args = 0, pretend = 0, frame = 4
260 0010 0330A0E3 @ frame_needed = 1, uses_anonymous_args = 0
261 0014 10300BE5 mov ip, sp
5:dummy.c **** return 0;
262 e 0x1
263 0018 0030A0E3 .uleb128 0x1
6:dummy.c **** }...
264 eb128 0x0
265 001c 0300A0E1 .ascii "__SOFTFP__ 1\000"
266 0020 08A89DE8 .byte 0x1
267 .uleb128 0x0
268 .ascii "__ARM_ARCH_4T__ 1\000"
312 .byte 0x1
DEFINED SYMBOLS
*ABS*:00000000 dummy.c
C:\DOCUME~1\MF9BB~1.CIA\IMPOST~1\Temp/ccA7aaaa.s:246 .text:00000000
main
C:\DOCUME~1\MF9BB~1.CIA\IMPOST~1\Temp/ccA7aaaa.s:251 .text:00000000
$a
NO UNDEFINED SYMBOLS
it seems that instruction and code are not aligned...
is this a bug?
thanks
Guest
#1171857
Massimiliano Cialdi wrote: > it seems that instruction and code are not aligned... > > is this a bug? The listing looks o.k. to me. What makes you thing that there is a bug?
Guest
#1171858
> The listing looks o.k. to me. What makes you thing that there is a bug?
Left part (addresses, opcode) of the disassembly does not correspond to
right part (instructions). Lines appear to be shifted by 1, up to 260.
Beyond, it gets weirder.
Guest
#1171859
WinARM: The assembly listing is fine without -g<any>, but garbage with debugging enabled. GNUARM: Correct in both cases.
A.K. wrote: > WinARM: The assembly listing is fine without -g<any>, but garbage with > debugging enabled. is this a bug from gcc official tree? Is this bug already be reported? thanks
A.K. wrote: > WinARM: The assembly listing is fine without -g<any>, but garbage with > debugging enabled. > > GNUARM: Correct in both cases. how GNUARM have corrected this problem? Is there a patch to apply? both WinARM and yagarto does not modify anything in the the source about the "real" compiler. So I wonder how GNUARM can be correct if is based on the same gcc sources. thanks
Guest
#1171862
GNUARM and WinARM use different system emulation layers, cygwin vs mingw or whatever. So source code could be identical, with the problem being some unfortunate side effects of a less than perfect API emulation.
Reply
Please log in before posting.