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
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?
> 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.
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
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.
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.