Hello Per,
> In my snapgear tree, about the same as uClinux tree, there are two
> previous gdbserver attempts. One is user/gdbserver and the other
user/gdb.
> Didn't get any of those working so therefore the birth of a third one.
Same here...
> Yes, the Makefile should be feed with values from the uClinux build
env.
> I use the concept of gluemakefiles (you all be pretty tired of me
debating
> about those soon :)
Gluemakefiles? Never heard about that. Google don't seem to have any
clue about it, too.
> Therefore, create a directory user/gdb_gdbserver and put the Makefile
> therein.
> Extract gdb-6.6 in here and apply at least the makefile patch,
probably
> also the gdbserver patch as we are on same arch.
> You also need to hook this directory into uClinux via editing
> config/config.in and user/Makefile.
Done that. In addition, I had to make some little modifications to get
it
compile. Most notably, I had to clean LDFLAGS for the host build:
diff -uwr /media/Kingston/gdb/Makefile ./Makefile
--- /media/Kingston/gdb/Makefile 2007-03-14 16:18:44.000000000
+0100
+++ ./Makefile 2007-03-19 09:59:45.000000000 +0100
@@ -6,22 +6,27 @@
PKG=gdb-6.6
HOST=
-HOST_ENV=CC= CFLAGS=
+HOST_ENV=CC= CFLAGS= LDFLAGS=
TGT=arm-linux
TGT_ENV=
all: build_host build_target
-$(PKG)/build/Makefile:
- mkdir $(PKG)/build
+$(PKG):
+ tar xjvf /m/s/spool/builds/uclinux/incoming/$(PKG).tar.bz2
+
+$(PKG)/build/Makefile: $(PKG)
+ mkdir -p $(PKG)/build
cd $(PKG)/build && $(HOST_ENV) ../configure --target=$(TGT) \
--with-sysroot
+ patch -p0 <makefile_var_fixup.patch
+ patch -p0 <gdbserver.patch
build_host: $(PKG)/build/Makefile
$(MAKE) -C $(PKG)/build
-$(PKG)/build-$(TGT)/gdbserver/Makefile:
+$(PKG)/build-$(TGT)/gdbserver/Makefile: $(PKG)
mkdir -p $(PKG)/build-$(TGT)/gdbserver
cd $(PKG)/build-$(TGT)/gdbserver && \
$(TGT_ENV) ../../gdb/gdbserver/configure --host=$(TGT)
With this, the compile succeeds, I can connect to the server, but I get
a Oops when I issue a "step" command.
It seems to be a problem with get_user_pages (called from the ptrace()
call).
I have checked with
http://www.ucdot.org/article.pl?sid=03/01/07/0214244&mode=thread
This article seems to be pretty much outdated, btw.
At least the vfork, float, qOffsets and PEEKUSR problems seem to be
already
addressed in vanilla gdb. But I am confused about the send_area()
thing. It
looks like the code has changed a lot since then. But since the
send_area()
patch seems to be closely related to ptrace(), I guess this is where my
Oops comes from.
Here's the output from ksymoops:
ksymoops 2.4.11 on i686 2.6.16.27-0.6-smp. Options used
-V (specified)
-K (specified)
-L (specified)
-O (specified)
-m ../../linux-2.4.32/System.map (specified)
-t elf32-littlearm
Internal error: Oops: 0
CPU: 0
pc : [<81030aa0>] lr : [<fe9d4000>] Not tainted
Using defaults from ksymoops -a i386
sp : 814efea8 ip : 7fb5c010 fp : 814efecc
r10: 81153d7c r9 : 8167b2a0 r8 : 811657b4
r7 : 814efeec r6 : 814efee8 r5 : 00000001 r4 : 00000000
r3 : 20000093 r2 : 81188010 r1 : 20000013 r0 : 00000000
Flags: nzCv IRQs off FIQs on Mode SVC_32 Segment user
Control: 0
Process gdbserver (pid: 54, stackpage=814ef000)
814efe80:
fe9d4000 81030aa0
814efea0: 20000093 ffffffff 8167b2b4 fffffffd 00000000 814ee000
814eff24 00000004
814efec0: 814eff18 814efed0 8102445c 81030a3c 00000000 00000001
814efeec 814efee8
814efee0: 8167b2b4 814eff24 00000000 7fb5c010 8156a000 fffffffd
814b7e74 814ee000
814eff00: 810159c0 0000001a 814b0004 814eff90 814eff1c 8101741c
81024284 00000000
814eff20: 814eff2c 814efea4 00000000 814efe98 00000001 00000000
00000000 00000008
814eff40: 00000000 811a5804 814ee000 810159c0 814b0004 814eff78
814eff64 810b98b4
814eff60: 810b97d8 00000000 00000000 814effac 8156a000 fffffffd
814b7e74 814ee000
814eff80: 810159c0 814effac 814eff94 8101781c 81017384 00000001
00000001 00000000
814effa0: 00000000 814effb0 81015820 81017724 00000001 8101b284
00000001 00000037
814effc0: 00000000 814b7e74 00000001 00000001 00000000 00000000
00000000 814b7e90
814effe0: 814b0004 814b7ec8 00000000 814b7e6c 814da5f0 814da59c
80000010 00000001
Backtrace:
Function entered at [<81030a2c>] from [<8102445c>]
Function entered at [<81024274>] from [<8101741c>]
Function entered at [<81017374>] from [<8101781c>]
r8 = 810159C0 r7 = 814EE000 r6 = 814B7E74 r5 = FFFFFFFD
r4 = 8156A000
Function entered at [<81017714>] from [<81015820>]
r6 = 00000000 r5 = 00000001 r4 = 00000001
Code: e3813080 e121f003 (e59c2014) e2822001 e58c2014
>>PC; 81030aa0 <get_user_pages+74/a8> <=====
>>r10; 81153d7c <mem_map+0/4>
>>r8; 811657b4 <dummy_vma.792+0/4c>
>>r2; 81188010 <_end_kernel+10/????>
Trace; 81030a2c <get_user_pages+0/a8>
Trace; 8102445c <access_process_vm+1e8/20c>
Trace; 81024274 <access_process_vm+0/20c>
Trace; 8101741c <do_ptrace+a8/3a0>
Trace; 81017374 <do_ptrace+0/3a0>
Trace; 8101781c <sys_ptrace+108/154>
>>r8; 810159c0 <sys_call_table+0/0>
Trace; 81017714 <sys_ptrace+0/154>
Trace; 81015820 <ret_fast_syscall+0/38>
Code; 81030a98 <get_user_pages+6c/a8>
00000000 <_PC>:
Code; 81030a98 <get_user_pages+6c/a8>
0: e3813080 orr r3, r1, #128 ; 0x80
Code; 81030a9c <get_user_pages+70/a8>
4: e121f003 msr CPSR_c, r3
Code; 81030aa0 <get_user_pages+74/a8> <=====
8: e59c2014 ldr r2, [ip, #20] <=====
Code; 81030aa4 <get_user_pages+78/a8>
c: e2822001 add r2, r2, #1 ; 0x1
Code; 81030aa8 <get_user_pages+7c/a8>
10: e58c2014 str r2, [ip, #20]
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
