[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] GCL on mingw
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] GCL on mingw |
Date: |
15 Dec 2003 14:58:04 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
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.
> 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? I
forgot what your 'info dll' report was, but I believe it did not
contain the address for sbrk reported above, which is reasonably close
to initlisp, as would be expected if you were in the local sbrk
routine. Also, just try setting a breakpoint manually with 'b
unexnt.c:xxx', where xxx is a line number inside sbrk.
Actually, you can see this explicitly from the call to VirtualAlloc in
the disassembly you provide. If all else fails, you can 'b *0x478298'
to break at that assembler point, and inspect the four arguments
pushed to the stack immediately prior. For example, if you really
have to, you could 'i reg esp' at that point, and then 'p/x *((int
*)<esp value>-16)@32' to see the arguments. You can even change them
before the call with 'p ((int *)<esp value>)[offset]=new_value',
though this should hardly be necessary. I'd very much expect these to
be referrable by their C code names as listed in unexnt.c.
Also, for future reference, if you are stopping at a function in an
external lib, gdb reports it like this:
Breakpoint 1, 0x401a1006 in sbrk () from /lib/libc.so.6
Take care,
> from GDB.
> When the function (sbrk) is done executing, GDB will silently
> stop (instead of continuing to evaluate the expression containing
> the function call).
> disassemble
> Dump of assembler code for function sbrk:
> 0x478163 <sbrk>: push %ebp
> 0x478164 <sbrk+1>: mov %esp,%ebp
> 0x478166 <sbrk+3>: sub $0x18,%esp
> 0x478169 <sbrk+6>: mov 0x8(%ebp),%eax
> 0x47816c <sbrk+9>: mov %eax,0xfffffff8(%ebp)
> 0x47816f <sbrk+12>: cmpl $0xf0a0f0a0,0x53b500
> 0x478179 <sbrk+22>: jne 0x4781b8 <sbrk+85>
> 0x47817b <sbrk+24>: call 0x478115 <allocate_heap>
> 0x478180 <sbrk+29>: mov %eax,0x53b500
> 0x478185 <sbrk+34>: cmpl $0x0,0x53b500
> 0x47818c <sbrk+41>: jne 0x47819a <sbrk+55>
> 0x47818e <sbrk+43>: movl $0x0,0xffffffec(%ebp)
> 0x478195 <sbrk+50>: jmp 0x4782d4 <sbrk+369>
> 0x47819a <sbrk+55>: mov 0x53b500,%eax
> 0x47819f <sbrk+60>: mov %eax,0x53b504
> 0x4781a4 <sbrk+65>: mov 0x53b504,%eax
> 0x4781a9 <sbrk+70>: mov %eax,0x53b508
> 0x4781ae <sbrk+75>: mov 0x53b510,%eax
> 0x4781b3 <sbrk+80>: mov %eax,0x53b50c
> 0x4781b8 <sbrk+85>: mov 0x53b504,%eax
> 0x4781bd <sbrk+90>: mov %eax,0xfffffffc(%ebp)
> 0x4781c0 <sbrk+93>: cmpl $0x0,0xfffffff8(%ebp)
> 0x4781c4 <sbrk+97>: jns 0x47825f <sbrk+252>
> 0x4781ca <sbrk+103>: lea 0xfffffff8(%ebp),%eax
> 0x4781cd <sbrk+106>: negl (%eax)
> 0x4781cf <sbrk+108>: mov 0xfffffff8(%ebp),%edx
> 0x4781d2 <sbrk+111>: mov 0x53b504,%eax
> 0x4781d7 <sbrk+116>: sub %edx,%eax
> 0x4781d9 <sbrk+118>: cmp 0x53b500,%eax
> 0x4781df <sbrk+124>: jae 0x4781ed <sbrk+138>
> 0x4781e1 <sbrk+126>: movl $0x0,0xffffffec(%ebp)
> 0x4781e8 <sbrk+133>: jmp 0x4782d4 <sbrk+369>
> 0x4781ed <sbrk+138>: mov 0xfffffff8(%ebp),%edx
> 0x4781f0 <sbrk+141>: mov 0x53b504,%eax
> 0x4781f5 <sbrk+146>: sub %edx,%eax
> 0x4781f7 <sbrk+148>: mov %eax,0xfffffff0(%ebp)
> 0x4781fa <sbrk+151>: mov 0x53b9e4,%eax
> 0x4781ff <sbrk+156>: mov 0xfffffff0(%ebp),%edx
> 0x478202 <sbrk+159>: add %eax,%edx
> 0x478204 <sbrk+161>: mov 0x53b9e4,%eax
> 0x478209 <sbrk+166>: not %eax
> 0x47820b <sbrk+168>: and %edx,%eax
> 0x47820d <sbrk+170>: mov %eax,0xfffffff0(%ebp)
> 0x478210 <sbrk+173>: mov 0xfffffff0(%ebp),%edx
> 0x478213 <sbrk+176>: mov 0x53b508,%eax
> 0x478218 <sbrk+181>: sub %edx,%eax
> 0x47821a <sbrk+183>: mov %eax,0xfffffff4(%ebp)
> 0x47821d <sbrk+186>: mov 0xfffffff0(%ebp),%eax
> 0x478220 <sbrk+189>: mov %eax,0x53b508
> 0x478225 <sbrk+194>: cmpl $0x0,0xfffffff4(%ebp)
> 0x478229 <sbrk+198>: jle 0x478254 <sbrk+241>
> 0x47822b <sbrk+200>: sub $0x4,%esp
> 0x47822e <sbrk+203>: push $0x4000
> 0x478233 <sbrk+208>: pushl 0xfffffff4(%ebp)
> 0x478236 <sbrk+211>: pushl 0x53b508
> 0x47823c <sbrk+217>: call 0x531c00 <address@hidden>
> 0x478241 <sbrk+222>: add $0x4,%esp
> 0x478244 <sbrk+225>: test %eax,%eax
> 0x478246 <sbrk+227>: jne 0x478254 <sbrk+241>
> 0x478248 <sbrk+229>: movl $0x0,0xffffffec(%ebp)
> 0x47824f <sbrk+236>: jmp 0x4782d4 <sbrk+369>
> 0x478254 <sbrk+241>: mov 0xfffffff8(%ebp),%eax
> 0x478257 <sbrk+244>: sub %eax,0x53b504
> 0x47825d <sbrk+250>: jmp 0x4782ce <sbrk+363>
> 0x47825f <sbrk+252>: cmpl $0x0,0xfffffff8(%ebp)
> 0x478263 <sbrk+256>: jle 0x4782ce <sbrk+363>
> 0x478265 <sbrk+258>: mov 0xfffffff8(%ebp),%eax
> 0x478268 <sbrk+261>: mov 0x53b504,%edx
> 0x47826e <sbrk+267>: add %eax,%edx
> 0x478270 <sbrk+269>: mov 0x53b510,%eax
> 0x478275 <sbrk+274>: add 0x53b500,%eax
> 0x47827b <sbrk+280>: cmp %eax,%edx
> 0x47827d <sbrk+282>: jbe 0x478288 <sbrk+293>
> 0x47827f <sbrk+284>: movl $0x0,0xffffffec(%ebp)
> 0x478286 <sbrk+291>: jmp 0x4782d4 <sbrk+369>
> 0x478288 <sbrk+293>: push $0x4
> 0x47828a <sbrk+295>: push $0x1000
> 0x47828f <sbrk+300>: pushl 0xfffffff8(%ebp)
> 0x478292 <sbrk+303>: pushl 0x53b504
> 0x478298 <sbrk+309>: call 0x531bd0 <address@hidden>
> 0x47829d <sbrk+314>: test %eax,%eax
> 0x47829f <sbrk+316>: jne 0x4782aa <sbrk+327>
> 0x4782a1 <sbrk+318>: movl $0x0,0xffffffec(%ebp)
> 0x4782a8 <sbrk+325>: jmp 0x4782d4 <sbrk+369>
> 0x4782aa <sbrk+327>: mov 0xfffffff8(%ebp),%eax
> 0x4782ad <sbrk+330>: add %eax,0x53b504
> 0x4782b3 <sbrk+336>: mov 0x53b9e4,%eax
> 0x4782b8 <sbrk+341>: mov 0x53b504,%edx
> 0x4782be <sbrk+347>: add %eax,%edx
> 0x4782c0 <sbrk+349>: mov 0x53b9e4,%eax
> 0x4782c5 <sbrk+354>: not %eax
> 0x4782c7 <sbrk+356>: and %edx,%eax
> 0x4782c9 <sbrk+358>: mov %eax,0x53b508
> 0x4782ce <sbrk+363>: mov 0xfffffffc(%ebp),%eax
> 0x4782d1 <sbrk+366>: mov %eax,0xffffffec(%ebp)
> 0x4782d4 <sbrk+369>: mov 0xffffffec(%ebp),%eax
> 0x4782d7 <sbrk+372>: leave
> 0x4782d8 <sbrk+373>: ret
> End of assembler dump.
> (gdb) l
> in tmp-diveby3.s
> (gdb) 1 tmp-diveby3.s: No such file or directory.
>
>
> > Please repeat the steps below, and after the first sbrk,
> > do 'b sbrk', then with the second 'p sbrk(4096)', step into the
> > routine line by line and report where it fails. I'd like to see the
> > result of p get_reserved_heap_size ()
> > If the routine fails at the VirtualAlloc call, try modifying the call
> > by increasing the first argument by some amount, thereby deternining
> > whether a skip is needed. Also would like the man page if any for
> > VirtualAlloc.
> > Take care,
> > "Vadim V. Zhytnikov" <address@hidden> writes:
> >
> >>Camm Maguire ?????:
> >>
> >>>Greetings!
> >>>"Vadim V. Zhytnikov" <address@hidden> writes:
> >>>
> >>>
> >>>>&j 0x22ff64
> >>>>&Cnil_body 0x54d1a0
> >>>>core_end 0x101c8000
> >>>>
> >>>
> >>>OK, given that you are having problems around 65000 pages (p/x
> >>>65000*4096 + 0x101c8000=0x1ffb0000)
> >>>I'm guessing something, most likely the shared library area, starts
> >>>at 0x20000000. Is there any way that you can confirm this? What is
> >>>the max data segment size returned by ulimit -a? Should be
> >>>unlimited. At the above break point in gdb, can you print the results
> >>>of:
> >>>p sbrk(65000*4096)
> >>>then keep running 'p sbrk(xxx*4096)' with some reasonable interval
> >>>xxx
> >>>until you get over 0x20000000, and let me know if there is a jump and
> >>>if so how big.
> >>>
> >>
> >>=================================================================
> >>(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 core_end
> >>$1 = 0x101c8000
> >>(gdb) p /x sbrk(65080*4096)
> >>$2 = 0x101c8000
> >>(gdb) p /x sbrk(4096)
> >>$3 = 0x0
> >>(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)
> >>=======================================================
> >>$ ulimit -a
> >>core file size (blocks) unlimited
> >>data seg size (kbytes) unlimited
> >>file size (blocks) unlimited
> >>open files 256
> >>pipe size (512 bytes) 8
> >>stack size (kbytes) 2046
> >>cpu time (seconds) unlimited
> >>max user processes 63
> >>virtual memory (kbytes) 2097152
> >>========================================================
> >>
> >>
> >>
> >> --
> >> Vadim V. Zhytnikov
> >>
> >> <address@hidden>
> >> <address@hidden>
> >>
> >>
> >>
> >>
> >>
> >
>
>
> --
> Vadim V. Zhytnikov
>
> <address@hidden>
> <address@hidden>
>
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
- 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 <=
- Re: [Gcl-devel] GCL on mingw, Vadim V. Zhytnikov, 2003/12/16
- 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