[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] GCL on mingw
From: |
Vadim V. Zhytnikov |
Subject: |
Re: [Gcl-devel] GCL on mingw |
Date: |
Tue, 16 Dec 2003 12:30:45 +0300 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.5) Gecko/20031006 |
Camm Maguire ?????:
Greetings!
"Vadim V. Zhytnikov" <address@hidden> writes:
Camm Maguire ?????:
Hi Vadim! And thanks!
OK, so now I believe this build uses the sbrk emulation routine found
in unexnt.c.
I don't think so. First of all there is no unexnt.o file in the
/o directory. Second, I can't any line numbering information
Actually, I think my original statement was correct. Here is the line
from mingw.h:
/* use the slightly older unexec */
#define UNIXSAVE "unexnt.c"
You should have a unixsave.o, which should basically just be an
include in this case of unexnt.c.
Yes. I overlooked this.
when stopped at sbrk after 'p sbrk(4096)'. What I'm doing wrong?
Hrere is gdb session transcript:
$ gdb raw_gcl
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) br initlisp
Breakpoint 1 at 0x402df5
(gdb) r ./ <foo
Starting program:
C:\msys\1.0\home\vadim\gcl-debug\unixport/raw_gcl.exe ./ <foo
Breakpoint 1, 0x00402df5 in initlisp ()
(gdb) p /x sbrk(65080*4096)
$1 = 0x101c8000
(gdb) br sbrk
Breakpoint 2 at 0x478169
(gdb) p /x sbrk(4096)
Breakpoint 2, 0x00478169 in sbrk ()
(gdb) The program being debugged stopped while in a function called
How about try 'l' for list here, 'n' for next, or 's' for step?
This was first thing I tried. But result was confusing.
And only after some head scratching I understood the reason of
all my troubles. First, I have to instruct gdb about explicit
sources location at ../o and ../h and more serious second problem -
files in ../o were compiled without debug flag -g (it sees like
a configure/make bug at least on mingw). After rebuilding with
-g option for all files I've got the following gdb session.
Notice that get_reserver_heap_size() is equal to reserved_heap_size.
In this session I first did sbrk for 65079 pages, then for 1 more
pages tracing sbrk (success) and one more page (failure).
The failure is not at VirtuallMalloc but at simple condition
1049 if ((data_region_end + size) >
1050 (data_region_base + get_reserved_heap_size ()))
==============================================================
$ gdb raw_gcl
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) dir ./ ../o ../h ../
Source directories searched:
C:\msys\1.0\home\vadim\gcl-debug\unixport;C:\msys\1.0\home\vadim\gcl-debug\unixport/../o;C:\msys\1.0\home\vadim\gcl-debug\unixport/../h;C:\msys\1.0\home\vadim\gcl-debug\unixport/..;$cdir;$cwd
(gdb) br initlisp
Breakpoint 1 at 0x402df5: file main.c, line 403.
(gdb) r ./ <foo
Starting program: C:\msys\1.0\home\vadim\gcl-debug\unixport/raw_gcl.exe
./ <foo
Breakpoint 1, initlisp () at main.c:403
403
(gdb) l
398
399 static void
400 initlisp(void) {
401
402 int j;
403
404 if (NULL_OR_ON_C_STACK(&j) == 0
405 || NULL_OR_ON_C_STACK(Cnil) != 0
406 || (((unsigned long )core_end) !=0
407 && NULL_OR_ON_C_STACK(core_end) != 0))
(gdb) p /x &j
$1 = 0x22ff64
(gdb) p /x &Cnil_body
$2 = 0x54d1a0
(gdb) p /x core_end
$3 = 0x101c8000
(gdb) info dll
DLL Name Load Address
ntdll.dll 77f51000
C:\WINDOWS\system32\kernel32.dll 77e61000
C:\WINDOWS\system32\msvcrt.dll 77c01000
C:\WINDOWS\system32\user32.dll 77d31000
C:\WINDOWS\system32\gdi32.dll 77c61000
C:\WINDOWS\system32\advapi32.dll 77dc1000
C:\WINDOWS\system32\rpcrt4.dll 77cb1000
C:\WINDOWS\System32\wsock32.dll 71ab1000
C:\WINDOWS\System32\ws2_32.dll 71a91000
C:\WINDOWS\System32\ws2help.dll 71a81000
(gdb) p /x sbrk(65079*4096)
$4 = 0x101c8000
(gdb) br sbrk
Breakpoint 2 at 0x478169: file unexnt.c, line 993.
(gdb) p /x sbrk(4096)
Breakpoint 2, sbrk (increment=4096) at unexnt.c:993
993 long size = (long) increment;
(gdb) The program being debugged stopped while in a function called from
GDB.
When the function (sbrk) is done executing, GDB will silently
stop (instead of continuing to evaluate the expression containing
the function call).
l
988 /* Emulate Unix sbrk. */
989 void *
990 sbrk (unsigned long increment)
991 {
992 void *result;
993 long size = (long) increment;
994
995 /* Allocate our heap if we haven't done so already. */
996 if (data_region_base == UNINIT_PTR)
997 {
(gdb) s
996 if (data_region_base == UNINIT_PTR)
(gdb) s
1015 result = data_region_end;
(gdb) s
1018 if (size < 0)
(gdb) p data_region_base
$5 = (unsigned char *) 0x10100000 "\r"
(gdb) p data_region_end
$6 = (unsigned char *) 0x1ffff000 <Address 0x1ffff000 out of bounds>
(gdb) p data_region_size
$7 = 267386880
(gdb) p reserved_heap_size
$8 = 267386880
(gdb) s
1046 else if (size > 0)
(gdb) s
1049 if ((data_region_end + size) >
(gdb) l
1044 }
1045 /* If size is positive, grow the heap by committing reserved
pages. */
1046 else if (size > 0)
1047 {
1048 /* Sanity checks. */
1049 if ((data_region_end + size) >
1050 (data_region_base + get_reserved_heap_size ()))
1051 return NULL;
1052
1053 /* Commit more of our heap. */
(gdb) s
1054 if (VirtualAlloc (data_region_end, size, MEM_COMMIT,
(gdb) s
1057 data_region_end += size;
(gdb) s
1061 real_data_region_end = (unsigned char *)
(gdb) s
1065 return result;
(gdb) s
1066 }
(gdb) l
1061 real_data_region_end = (unsigned char *)
1062 ((long) (data_region_end + syspage_mask) & ~syspage_mask);
1063 }
1064
1065 return result;
1066 }
1067
1068 /* Recreate the heap from the data that was dumped to the
executable.
1069 EXECUTABLE_PATH tells us where to find the executable. */
1070 void
(gdb) finish
Run till exit from #0 sbrk (increment=4096) at unexnt.c:1066
Value returned is $9 = (void *) 0x1ffff000
(gdb) p /x sbrk(4096)
Breakpoint 2, sbrk (increment=4096) at unexnt.c:993
993 long size = (long) increment;
(gdb) The program being debugged stopped while in a function called from
GDB.
When the function (sbrk) is done executing, GDB will silently
stop (instead of continuing to evaluate the expression containing
the function call).
s
996 if (data_region_base == UNINIT_PTR)
(gdb) s
1015 result = data_region_end;
(gdb) s
1018 if (size < 0)
(gdb) s
1046 else if (size > 0)
(gdb) p data_region_base
$10 = (unsigned char *) 0x10100000 "\r"
(gdb) p data_region_end
$11 = (unsigned char *) 0x20000000 <Address 0x20000000 out of bounds>
(gdb) p data_region_size
$12 = 267386880
(gdb) p reserved_heap_size
$13 = 267386880
(gdb) s
1049 if ((data_region_end + size) >
(gdb) l
1044 }
1045 /* If size is positive, grow the heap by committing reserved
pages. */
1046 else if (size > 0)
1047 {
1048 /* Sanity checks. */
1049 if ((data_region_end + size) >
1050 (data_region_base + get_reserved_heap_size ()))
1051 return NULL;
1052
1053 /* Commit more of our heap. */
(gdb) s
1051 return NULL;
(gdb) s
1066 }
(gdb) finish
Run till exit from #0 sbrk (increment=4096) at unexnt.c:1066
Value returned is $14 = (void *) 0x0
(gdb)
=======================================================================
--
Vadim V. Zhytnikov
<address@hidden>
<address@hidden>
- Re: [Gcl-devel] GCL on mingw, (continued)
- Re: [Gcl-devel] GCL on mingw, Vadim V. Zhytnikov, 2003/12/12
- Re: [Gcl-devel] GCL on mingw, Vadim V. Zhytnikov, 2003/12/12
- Re: [Gcl-devel] GCL on mingw, Camm Maguire, 2003/12/12
- Re: [Gcl-devel] GCL on mingw, Vadim V. Zhytnikov, 2003/12/13
- Re: [Gcl-devel] GCL on mingw, Camm Maguire, 2003/12/13
- Re: [Gcl-devel] GCL on mingw, Vadim V. Zhytnikov, 2003/12/14
- Re: [Gcl-devel] GCL on mingw, Camm Maguire, 2003/12/15
- Re: [Gcl-devel] GCL on mingw,
Vadim V. Zhytnikov <=
- Re: [Gcl-devel] GCL on mingw, Camm Maguire, 2003/12/16
- Re: [Gcl-devel] GCL on mingw, Vadim V. Zhytnikov, 2003/12/16
- Re: [Gcl-devel] GCL on mingw, Camm Maguire, 2003/12/16