This is the mail archive of the
ecos-bugs@sourceware.org
mailing list for the eCos project.
[Bug 1001468] eCos GNU tools 4.6.3
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: unassigned at bugs dot ecos dot sourceware dot org
- Date: Fri, 30 Mar 2012 16:01:09 +0100
- Subject: [Bug 1001468] eCos GNU tools 4.6.3
- Auto-submitted: auto-generated
- References: <bug-1001468-777@http.bugs.ecos.sourceware.org/>
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001468
--- Comment #42 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-30 16:00:55 BST ---
Hi JIfl
(In reply to comment #41)
Now I have enough Cortex-M4F architectural support to do some GDB testing. I
have applied the attachment (id=1648) and it seems to work with following
issues:
1. Remote 'g' packet reply is too long
If I connect to gdb server (RedBoot on Cortex-M4F) prior to submit the elf file
I get the error /Remote 'g' packet reply is too long/:
--- Capture -------
(gdb) target remote 192.168.209.246:9000
Remote debugging using 192.168.209.246:9000
Remote 'g' packet reply is too long:
01550000100000000000000010000000000000000000000000000000000000000000000000000000
00000000000000000000000030ffff77d56d00000255000000000000015500001000000000000000
10000000000000000000000000000000000000000000000000000000000000000000000000000000
30ffff77d56d0000025500000000000100000000d56f0000fdbfffffeff7ffffdbf3efbfc56d0000
f3fdff7f6fe777fdfe6f7ffffceaffffffffffffebf7ff7feffffeffffffefffbfbfff5d98feff77
(gdb)
--- Capture END -------
If I introduce a target file before connection, GDB get's prepared for this
packet and accepts connection.
--- Capture -------
(gdb) file fpinttest.elf
Reading symbols from
/home/vae/Proekti/pd/sem/rtlinux/posix_lin_ecos/bin/fpinttest.elf...done.
(gdb) target remote 192.168.209.246:9000
Remote debugging using 192.168.209.246:9000
0x00005502 in ?? ()
(gdb) info all-registers
r0 0x5501 21761
r1 0x10 16
r2 0x0 0
r3 0x10 16
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x0 0
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x77ffff30 0x77ffff30
lr 0x6dd5 28117
pc 0x5502 0x5502
xpsr 0x0 0
d0 3.3951943406806876e-313 (raw 0x0000001000005501)
d1 3.3951932655444357e-313 (raw 0x0000001000000000)
d2 0 (raw 0x0000000000000000)
d3 0 (raw 0x0000000000000000)
d4 0 (raw 0x0000000000000000)
d5 0 (raw 0x0000000000000000)
d6 1.0564842675187554e+270 (raw 0x77ffff3000000000)
d7 4.61788724168779e-310 (raw 0x0000550200006dd5)
d8 8.289046058458095e-317 (raw 0x0000000001000000)
d9 -nan(0xfbffd00006fd5) (raw 0xffffbffd00006fd5)
d10 -0.99851799011207543 (raw 0xbfeff3dbfffff7ef)
d11 nan(0xffdf300006dc5) (raw 0x7ffffdf300006dc5)
d12 -1.3797595269860335e+306 (raw 0xff7f6ffefd77e76f)
d13 -nan(0xfffffffffeafc) (raw 0xffffffffffffeafc)
d14 -nan(0xeffef7ffff7eb) (raw 0xfffeffef7ffff7eb)
d15 6.1945292423959159e+144 (raw 0x5dffbfbfffefffff)
fpscr 0x77fffe98 2013265560
s0 3.04936559e-41 (raw 0x00005501)
s1 2.24207754e-44 (raw 0x00000010)
s2 0 (raw 0x00000000)
s3 2.24207754e-44 (raw 0x00000010)
s4 0 (raw 0x00000000)
s5 0 (raw 0x00000000)
s6 0 (raw 0x00000000)
s7 0 (raw 0x00000000)
s8 0 (raw 0x00000000)
s9 0 (raw 0x00000000)
---Type <return> to continue, or q <return> to quit---
s10 0 (raw 0x00000000)
s11 0 (raw 0x00000000)
s12 0 (raw 0x00000000)
s13 1.0384465e+34 (raw 0x77ffff30)
s14 3.94003089e-41 (raw 0x00006dd5)
s15 3.04950572e-41 (raw 0x00005502)
s16 2.3509887e-38 (raw 0x01000000)
s17 0 (raw 0x00000000)
s18 4.01177737e-41 (raw 0x00006fd5)
s19 -nan(0x7fbffd) (raw 0xffffbffd)
s20 -nan(0x7ff7ef) (raw 0xfffff7ef)
s21 -1.87462938 (raw 0xbfeff3db)
s22 3.93778881e-41 (raw 0x00006dc5)
s23 nan(0x7ffdf3) (raw 0x7ffffdf3)
s24 -2.05950617e+37 (raw 0xfd77e76f)
s25 -3.39534636e+38 (raw 0xff7f6ffe)
s26 -nan(0x7feafc) (raw 0xffffeafc)
s27 -nan(0x7fffff) (raw 0xffffffff)
s28 nan(0x7ff7eb) (raw 0x7ffff7eb)
s29 -nan(0x7effef) (raw 0xfffeffef)
s30 -nan(0x6fffff) (raw 0xffefffff)
s31 2.30358228e+18 (raw 0x5dffbfbf)
(gdb)
--- Capture END -------
This is probably not a problem when using gdb from command line, but it is with
Eclipse.
2. Potential eCos/RedBoot issues
Since register numbers are not consecutive there may be issue with some stub
eCos/Redboot functions: For instance stub_format_registers() requires
consecutive numbers.
Ilija.
P.S. I am going to open bug(s) on Cortex_M4F architectural support but for GDB
matters perhaps we continue in Bug 1001524.
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.