Message ID | 20141215222801.GA28138@host2.jankratochvil.net |
---|---|
State | New, archived |
Headers |
Received: (qmail 15642 invoked by alias); 15 Dec 2014 22:28:20 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 15619 invoked by uid 89); 15 Dec 2014 22:28:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 15 Dec 2014 22:28:13 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBFMS6lB011440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 15 Dec 2014 17:28:06 -0500 Received: from host2.jankratochvil.net (ovpn-116-142.ams2.redhat.com [10.36.116.142]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sBFMS20b014230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Dec 2014 17:28:04 -0500 Date: Mon, 15 Dec 2014 23:28:01 +0100 From: Jan Kratochvil <jan.kratochvil@redhat.com> To: Eli Zaretskii <eliz@gnu.org> Cc: brobecker@adacore.com, yao@codesourcery.com, gdb-patches@sourceware.org, ktietz@redhat.com Subject: [patch] compile: Fix MinGW build [Re: [mingw rfc] Add mkdtemp to gdb/gnulib/] Message-ID: <20141215222801.GA28138@host2.jankratochvil.net> References: <87egs2vcfu.fsf@codesourcery.com> <20141214182341.GA2908@host2.jankratochvil.net> <87a92pvc0w.fsf@codesourcery.com> <20141215124358.GU5457@adacore.com> <20141215171225.GA19674@host2.jankratochvil.net> <20141215181449.GA5457@adacore.com> <20141215182057.GA22226@host2.jankratochvil.net> <20141215183554.GB5457@adacore.com> <20141215184014.GA22610@host2.jankratochvil.net> <83y4q8wxk7.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <83y4q8wxk7.fsf@gnu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes |
Commit Message
Jan Kratochvil
Dec. 15, 2014, 10:28 p.m. UTC
On Mon, 15 Dec 2014 19:57:28 +0100, Eli Zaretskii wrote: > > On Mon, 15 Dec 2014 04:15:43 +0100, Yao Qi wrote: > > # or maybe we have to use win32 api, such as GetTempPath and GetRandomFileName. > > If you write it, I can test it. In the end I have managed to test it by Wine myself: $ wine build_win32/gdb/gdb.exe -q build_win32/gdb/gdb.exe -ex start -ex 'compile code 1' -ex 'set confirm no' -ex quit [...] Temporary breakpoint 1, main (argc=1, argv=0x241418) at ../../gdb/gdb.c:29 29 args.argc = argc; Could not load libcc1.so: Module not found. Even if it managed to load libcc1.so (it needs host-dependent name libcc1.dll) then it would soon end up at least on: default_infcall_mmap: error (_("This target does not support inferior memory allocation by mmap.")); As currently there is only: linux-tdep.c: set_gdbarch_infcall_mmap (gdbarch, linux_infcall_mmap); While one could debug Linux targets from MS-Windows host I find it somehow overcomplicated now when we are trying to get it running at least on native Linux x86*. The 'compile' project needs a larger port effort to run on MS-Windows. OK for check-in? Thanks, Jan gdb/ChangeLog 2014-12-15 Jan Kratochvil <jan.kratochvil@redhat.com> Fix MinGW compilation. * compile/compile.c (get_compile_file_tempdir): Call error on _WIN32.
Comments
On Mon, 15 Dec 2014 23:28:01 +0100, Jan Kratochvil wrote:
> The 'compile' project needs a larger port effort to run on MS-Windows.
For example there is also
compile/compile.c:
zap = concat ("rm -rf ", dir, (char *) NULL);
system (zap);
which is AFAIK a no-go on MinGW.
Jan
> Date: Mon, 15 Dec 2014 23:28:01 +0100 > From: Jan Kratochvil <jan.kratochvil@redhat.com> > Cc: brobecker@adacore.com, yao@codesourcery.com, gdb-patches@sourceware.org, > ktietz@redhat.com > > Even if it managed to load libcc1.so (it needs host-dependent name libcc1.dll) > then it would soon end up at least on: > > default_infcall_mmap: > error (_("This target does not support inferior memory allocation by mmap.")); > > As currently there is only: > > linux-tdep.c: > set_gdbarch_infcall_mmap (gdbarch, linux_infcall_mmap); Why is mmap needed here? > OK for check-in? > > > Thanks, > Jan > gdb/ChangeLog > 2014-12-15 Jan Kratochvil <jan.kratochvil@redhat.com> > > Fix MinGW compilation. > * compile/compile.c (get_compile_file_tempdir): Call error on _WIN32. > > --- ./gdb/compile/compile.c 2014-12-14 02:48:38.000000000 +0100 > +++ ./gdb/compile/compile.c 2014-12-15 23:21:28.788716340 +0100 > @@ -191,7 +191,11 @@ get_compile_file_tempdir (void) > > strcpy (tname, TEMPLATE); > #undef TEMPLATE > +#ifdef _WIN32 > + error (_("mkdtemp needs to be implemented for MS-Windows hosts")); > +#else > tempdir_name = mkdtemp (tname); > +#endif > if (tempdir_name == NULL) > perror_with_name (_("Could not make temporary directory")); I think _WIN32 will catch Cygwin as well, which is not what you want. Why not just check HAVE_MKDTEMP?
> Date: Mon, 15 Dec 2014 23:55:51 +0100 > From: Jan Kratochvil <jan.kratochvil@redhat.com> > Cc: brobecker@adacore.com, yao@codesourcery.com, gdb-patches@sourceware.org, > ktietz@redhat.com > > On Mon, 15 Dec 2014 23:28:01 +0100, Jan Kratochvil wrote: > > The 'compile' project needs a larger port effort to run on MS-Windows. > > For example there is also > > compile/compile.c: > zap = concat ("rm -rf ", dir, (char *) NULL); > system (zap); Yuck! Do we really allow such atrocities in GDB? What if 'rm' is some unrelated or even malicious script? I think this should be replaced by suitable C function calls. IMO, this kind of programming is OK for prototyping, but not for the final code.
----- Ursprüngliche Mail ----- > > Date: Mon, 15 Dec 2014 23:55:51 +0100 > > From: Jan Kratochvil <jan.kratochvil@redhat.com> > > Cc: brobecker@adacore.com, yao@codesourcery.com, > > gdb-patches@sourceware.org, > > ktietz@redhat.com > > > > On Mon, 15 Dec 2014 23:28:01 +0100, Jan Kratochvil wrote: > > > The 'compile' project needs a larger port effort to run on MS-Windows. > > > > For example there is also > > > > compile/compile.c: > > zap = concat ("rm -rf ", dir, (char *) NULL); > > system (zap); > > Yuck! Do we really allow such atrocities in GDB? What if 'rm' is > some unrelated or even malicious script? > > I think this should be replaced by suitable C function calls. IMO, > this kind of programming is OK for prototyping, but not for the final > code. > Ouch, to use console is for sure a bad thing. To use POSIX-shell commands is even worse. Why not using here instead an implementation using FTW-API? At least mingw-w64 added this API recently to runtime for gcc's sake, so implementation of an 'rm -rf' should be pretty easy. Kai
----- Ursprüngliche Mail ----- > > Date: Mon, 15 Dec 2014 23:28:01 +0100 > > From: Jan Kratochvil <jan.kratochvil@redhat.com> > > Cc: brobecker@adacore.com, yao@codesourcery.com, > > gdb-patches@sourceware.org, > > ktietz@redhat.com > > > > Even if it managed to load libcc1.so (it needs host-dependent name > > libcc1.dll) > > then it would soon end up at least on: > > > > default_infcall_mmap: > > error (_("This target does not support inferior memory allocation by > > mmap.")); > > > > As currently there is only: > > > > linux-tdep.c: > > set_gdbarch_infcall_mmap (gdbarch, linux_infcall_mmap); > > Why is mmap needed here? > > > OK for check-in? > > > > > > Thanks, > > Jan > > gdb/ChangeLog > > 2014-12-15 Jan Kratochvil <jan.kratochvil@redhat.com> > > > > Fix MinGW compilation. > > * compile/compile.c (get_compile_file_tempdir): Call error on _WIN32. > > > > --- ./gdb/compile/compile.c 2014-12-14 02:48:38.000000000 +0100 > > +++ ./gdb/compile/compile.c 2014-12-15 23:21:28.788716340 +0100 > > @@ -191,7 +191,11 @@ get_compile_file_tempdir (void) > > > > strcpy (tname, TEMPLATE); > > #undef TEMPLATE > > +#ifdef _WIN32 > > + error (_("mkdtemp needs to be implemented for MS-Windows hosts")); > > +#else > > tempdir_name = mkdtemp (tname); > > +#endif > > if (tempdir_name == NULL) > > perror_with_name (_("Could not make temporary directory")); > > I think _WIN32 will catch Cygwin as well, which is not what you want. > > Why not just check HAVE_MKDTEMP? > Well, _WIN32 isn't set necessarily for Cygwin. For Cygwin this define is just set if the windows.h header got included AFAIK. Anyway, there are better ways to check, and indeed HAVE_MKDTEMP seems to be the most correct check, isn't it? Kai
Hi Jan,
I tested your patch,
which appeared as an attached file named 1.sql,
which made it difficult to guess it was indeed the patch...
Nevertheless, your patch fixes compilation error for mingw32
and as such it should be committed as an obvious fix.
To go a little bit further, I tried to use
the compile command on the newly generated mingw32 GDB executable.
using ./gdb ./gdb
(with a minimal hello.c source code)
<<<< (top-gdb) compile code hello.c
returns
>>>> The program must be running for the compile command to work.
I am not sure why this restriction should apply.
(top-gdb) start
Temporary breakpoint 3 at 0x40158a: file ../../../binutils-gdb/gdb/gdb.c, line 28.
Starting program: E:\cygwin-32\home\Pierre\git\build\mult-mingw32\gdb\gdb.exe
[New Thread 6572.0x4e0]
Temporary breakpoint 3, main (argc=1, argv=0x3d4b30)
at ../../../binutils-gdb/gdb/gdb.c:28
(top-gdb) compile file hello.c
Could not load libcc1.so: "libcc1.so": Le module spécifié est introuvable.
(French meaning: "the specified module can't be found").
So the mkdtmp is not the only problem
for mingw compile support.
Pierre Muller
Jan Kratochvil <jan.kratochvil@redhat.com> writes: > In the end I have managed to test it by Wine myself: > > $ wine build_win32/gdb/gdb.exe -q build_win32/gdb/gdb.exe -ex start > -ex 'compile code 1' -ex 'set confirm no' -ex quit > [...] > Temporary breakpoint 1, main (argc=1, argv=0x241418) at ../../gdb/gdb.c:29 > 29 args.argc = argc; > Could not load libcc1.so: Module not found. > > Even if it managed to load libcc1.so (it needs host-dependent name libcc1.dll) > then it would soon end up at least on: > > default_infcall_mmap: > error (_("This target does not support inferior memory allocation by mmap.")); > > As currently there is only: > > linux-tdep.c: > set_gdbarch_infcall_mmap (gdbarch, linux_infcall_mmap); The module not found problem and unsupported mmap problem are separated ones. They are not related to the mkdtemp problem we are discussing here, IMO. > > While one could debug Linux targets from MS-Windows host I find it somehow > overcomplicated now when we are trying to get it running at least on native > Linux x86*. > > The 'compile' project needs a larger port effort to run on MS-Windows. If 'compile' feature on mingw/Windows doesn't work, why don't we disable it on Windows?
On 12/17/2014 01:21 AM, Yao Qi wrote: >> > >> > While one could debug Linux targets from MS-Windows host I find it somehow >> > overcomplicated now when we are trying to get it running at least on native >> > Linux x86*. >> > >> > The 'compile' project needs a larger port effort to run on MS-Windows. > If 'compile' feature on mingw/Windows doesn't work, why don't we disable > it on Windows? You mean, not compile the whole set of compile/ files on Windows? I think we're not that far off from making the command usable on all hosts. I'd rather keep it building everywhere, and guard the specific bits that need porting or better abstractions guarded with #if HAVE_FOO. Thanks, Pedro Alves
On 12/15/2014 10:28 PM, Jan Kratochvil wrote: > On Mon, 15 Dec 2014 19:57:28 +0100, Eli Zaretskii wrote: >>> On Mon, 15 Dec 2014 04:15:43 +0100, Yao Qi wrote: >>> # or maybe we have to use win32 api, such as GetTempPath and GetRandomFileName. >> >> If you write it, I can test it. > > In the end I have managed to test it by Wine myself: > > $ wine build_win32/gdb/gdb.exe -q build_win32/gdb/gdb.exe -ex start -ex 'compile code 1' -ex 'set confirm no' -ex quit > [...] > Temporary breakpoint 1, main (argc=1, argv=0x241418) at ../../gdb/gdb.c:29 > 29 args.argc = argc; > Could not load libcc1.so: Module not found. > > Even if it managed to load libcc1.so (it needs host-dependent name libcc1.dll) > then it would soon end up at least on: > > default_infcall_mmap: > error (_("This target does not support inferior memory allocation by mmap.")); > > As currently there is only: > > linux-tdep.c: > set_gdbarch_infcall_mmap (gdbarch, linux_infcall_mmap); > > While one could debug Linux targets from MS-Windows host I find it somehow > overcomplicated now when we are trying to get it running at least on native > Linux x86*. > > The 'compile' project needs a larger port effort to run on MS-Windows. > > OK for check-in? Can you send a version that does an autoconf check for mkdtemp instead? > + error (_("mkdtemp needs to be implemented for MS-Windows hosts")); I think the error text should be a bit more generic and not mention a particular implementation detail, like "Command not supported on this host." or some such -- I think the testsuite will need to be extended to handle this error, presumably in skip_compile_feature_tests. Thanks, Pedro Alves
Pedro Alves <palves@redhat.com> writes: > You mean, not compile the whole set of compile/ files on Windows? I think we're Yes. > not that far off from making the command usable on all hosts. I'd rather keep > it building everywhere, and guard the specific bits that need porting > or better abstractions guarded with #if HAVE_FOO. At least, user should get an explicit message that 'compile' command isn't supported if the user run the 'compile' command on Windows for example.
On 12/17/2014 11:40 AM, Yao Qi wrote: > At least, user should get an explicit message that 'compile' command > isn't supported if the user run the 'compile' command on Windows for example. Agreed. That's what I suggested in the other mail too: https://sourceware.org/ml/gdb-patches/2014-12/msg00475.html Would that be OK with you? Thanks, Pedro Alves
On 12/17/2014 07:43 PM, Pedro Alves wrote: > Agreed. That's what I suggested in the other mail too: > > https://sourceware.org/ml/gdb-patches/2014-12/msg00475.html > > Would that be OK with you? Yes, that is OK to me.
On Tue, 2014-12-16 at 05:39 +0200, Eli Zaretskii wrote: > > Date: Mon, 15 Dec 2014 23:55:51 +0100 > > From: Jan Kratochvil <jan.kratochvil@redhat.com> > > Cc: brobecker@adacore.com, yao@codesourcery.com, gdb-patches@sourceware.org, > > ktietz@redhat.com > > > > On Mon, 15 Dec 2014 23:28:01 +0100, Jan Kratochvil wrote: > > > The 'compile' project needs a larger port effort to run on MS-Windows. > > > > For example there is also > > > > compile/compile.c: > > zap = concat ("rm -rf ", dir, (char *) NULL); > > system (zap); > > Yuck! Do we really allow such atrocities in GDB? What if 'rm' is > some unrelated or even malicious script? > > I think this should be replaced by suitable C function calls. IMO, > this kind of programming is OK for prototyping, but not for the final > code. I am running into a different problem with the system call. I am building on Linux using the latest GCC and glibc (unreleased top of tree sources) and my build fails with: /scratch/sellcey/repos/nightly2/src/binutils-gdb/gdb/compile/compile.c:175:10: error: ignoring return value of 'system', declared with attribute warn_unused_result [-Werror=unused-result] cc1: all warnings being treated as errors make[1]: *** [compile.o] Error 1 If we don't get rid of the system call can we at least check the return value of system? Steve Ellcey sellcey@imgtec.com
Hi Pierre, On Tue, 16 Dec 2014 13:40:28 +0100, Pierre Muller wrote: > which appeared as an attached file named 1.sql, > which made it difficult to guess it was indeed the patch... The mail has: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename=1 So there was no ".sql" extension; there was just no extension at all. > To go a little bit further, I tried to use > the compile command on the newly generated mingw32 GDB executable. > > using ./gdb ./gdb > (with a minimal hello.c source code) > > <<<< (top-gdb) compile code hello.c > returns > >>>> The program must be running for the compile command to work. > I am not sure why this restriction should apply. I do not understand what it should do without running inferior. Or rather I can understand it but that would be a functionality completely unrelated to the current 'compile' functionality - which hooks into the running inferior. I would find it rather confusing myself. > (top-gdb) start > Temporary breakpoint 3 at 0x40158a: file ../../../binutils-gdb/gdb/gdb.c, line 28. > Starting program: E:\cygwin-32\home\Pierre\git\build\mult-mingw32\gdb\gdb.exe > [New Thread 6572.0x4e0] > > Temporary breakpoint 3, main (argc=1, argv=0x3d4b30) > at ../../../binutils-gdb/gdb/gdb.c:28 > (top-gdb) compile file hello.c > Could not load libcc1.so: "libcc1.so": Le module spécifié est introuvable. > (French meaning: "the specified module can't be found"). > > So the mkdtmp is not the only problem > for mingw compile support. That is correct, you need to build gcc-5.0 which contains libcc1.so. But that currently also will not work as it will get named libcc1.dll, you can read more in: https://sourceware.org/ml/gdb-patches/2014-12/msg00429.html Thanks, Jan
On Wed, 17 Dec 2014 12:43:35 +0100, Pedro Alves wrote: > On 12/17/2014 11:40 AM, Yao Qi wrote: > > > At least, user should get an explicit message that 'compile' command > > isn't supported if the user run the 'compile' command on Windows for example. > > Agreed. That's what I suggested in the other mail too: > > https://sourceware.org/ml/gdb-patches/2014-12/msg00475.html > > Would that be OK with you? This is not completely correct. With the patch above being checked in now the 'compile' command will still fail on: $ wine build_win32/gdb/gdb.exe -q build_win32/gdb/gdb.exe -ex start -ex 'compile code 1' -ex 'set confirm no' -ex quit [...] Temporary breakpoint 1, main (argc=1, argv=0x241418) at ../../gdb/gdb.c:29 29 args.argc = argc; Could not load libcc1.so: Module not found. It would need some special exception. So far it is obvious that one needs gcc-5.0 which "nobody" has. But after gcc-5.0 gets released MinGW gdb.exe will still print "Could not load libcc1.so" while (I expect) MinGW gcc-5.0 will have "libcc1.dll". Jan
On Tue, 16 Dec 2014 04:37:15 +0100, Eli Zaretskii wrote: > > default_infcall_mmap: > > error (_("This target does not support inferior memory allocation by mmap.")); > > > > As currently there is only: > > > > linux-tdep.c: > > set_gdbarch_infcall_mmap (gdbarch, linux_infcall_mmap); > > Why is mmap needed here? The project obviously needs something like: (gdb) call dlopen("just compile piece of code.so"); But as dlopen() is intrusive to the inferior Tom decided it is better to do much less intrusive (gdb) print mmap(...) instead and reimplement what inferior dlopen() does in gdb/compile/compile-object-load.c - which is being done. Without mmap() there is nowhere to load the compiled code at. Jan
> Date: Wed, 17 Dec 2014 20:17:55 +0100 > From: Jan Kratochvil <jan.kratochvil@redhat.com> > Cc: brobecker@adacore.com, yao@codesourcery.com, gdb-patches@sourceware.org, > ktietz@redhat.com > > > > linux-tdep.c: > > > set_gdbarch_infcall_mmap (gdbarch, linux_infcall_mmap); > > > > Why is mmap needed here? > > The project obviously needs something like: > (gdb) call dlopen("just compile piece of code.so"); > > But as dlopen() is intrusive to the inferior Tom decided it is better to do > much less intrusive > (gdb) print mmap(...) > > instead and reimplement what inferior dlopen() does > in gdb/compile/compile-object-load.c - which is being done. Why is dlopen "intrusive"? ISTM that using the Windows equivalent of dlopen is exactly the right thing here.
On Wed, 17 Dec 2014 20:31:18 +0100, Eli Zaretskii wrote: > Why is dlopen "intrusive"? ISTM that using the Windows equivalent of > dlopen is exactly the right thing here. First I do not want to advocate the mmap() + ld.so reimplementation too much as I would implement it the dlopen() way (at least in the initial implementation) myself. But AFAIK (but I do not know much) MS-Windows implements its dlopen-like feature in MS-Windows kernel which may be safe. Contrary to it GNU/Linux implements dlopen() fully in glibc - userland - calling from kernel only that mmap() to map the .so file from disk, map some new pages of memory etc. By having to modify the _r_debug.r_map link list which is in many times corrupted when debugging crashed program GDB would crash the inferior even more on 'compile code' command. Jan
On 12/17/2014 07:31 PM, Eli Zaretskii wrote: >> Date: Wed, 17 Dec 2014 20:17:55 +0100 >> From: Jan Kratochvil <jan.kratochvil@redhat.com> >> Cc: brobecker@adacore.com, yao@codesourcery.com, gdb-patches@sourceware.org, >> ktietz@redhat.com >> >>>> linux-tdep.c: >>>> set_gdbarch_infcall_mmap (gdbarch, linux_infcall_mmap); >>> >>> Why is mmap needed here? >> >> The project obviously needs something like: >> (gdb) call dlopen("just compile piece of code.so"); >> >> But as dlopen() is intrusive to the inferior Tom decided it is better to do >> much less intrusive >> (gdb) print mmap(...) >> >> instead and reimplement what inferior dlopen() does >> in gdb/compile/compile-object-load.c - which is being done. > > Why is dlopen "intrusive"? Pasting here what I said recently on a glibc thread, re. reasons for not using dlopen for this. Off the top of my head, I'm sure there are more: - The user might want to evaluate an expression while the program itself has just called dlopen and is now stopped inside it. This pesky dlopen recursion thing. It's best if GDB only calls async-signal safe functions behind the scenes, if possible. Of course if the injected expression involves calls to async-signal unsafe code that breaks the inferior, the user gets what she asked for. - The program might have not been linked with -ldl. - I suspect there may be issues with messing with symbol resolution and self library walks in the inferior too. Not sure if RTLD_LOCAL is enough. dlmopen might be a better fit, but hmm, that isn't very well supported in GDB/glibc. - A lower level mechanism has much better chances of working on more targets and runtimes-of-languages-other-than-C with minimal changes. > ISTM that using the Windows equivalent of dlopen is exactly the right thing here. That may well be, though I think that it's better if "info shared" doesn't show the modules injected into the inferior, which using LoadLibrary (Windows's dlopen) would give you. Note that set_gdbarch_infcall_mmap doesn't need to implement the whole feature set of mmap. We only need to be able to carve out a piece of memory. Should map trivially to VirtualAlloc. I expect that we'll end up using this same gdbarch hook to allocate memory in the inferior when we need to coerce variables to the inferior. We currently call "malloc" for that, which isn't ideal in the sense that the inferior can well be already inside malloc when we do that, leading do deadlock or corruption. Thanks, Pedro Alves
> Date: Wed, 17 Dec 2014 20:34:12 +0000 > From: Pedro Alves <palves@redhat.com> > CC: brobecker@adacore.com, yao@codesourcery.com, gdb-patches@sourceware.org, > ktietz@redhat.com > > Note that set_gdbarch_infcall_mmap doesn't need to implement the > whole feature set of mmap. We only need to be able to carve out a > piece of memory. Should map trivially to VirtualAlloc. That's true, but if this feature will work by doing the equivalent of dlopen, then it will most probably only ever work on GNU/Linux. Even there, we cannot really hope to do all this stuff by hand, do it safely, and then track all the changes in the OS to keep this working for the years to come. And good luck being able to do it at all on proprietary systems such as Windows, where you cannot simply examine the sources of the DLL loader. I conclude that sadly this feature is extremely limited, and will probably die very soon, unless we change its implementation to something more portable and safe.
On 12/18/2014 05:22 PM, Eli Zaretskii wrote: >> Date: Wed, 17 Dec 2014 20:34:12 +0000 >> From: Pedro Alves <palves@redhat.com> >> CC: brobecker@adacore.com, yao@codesourcery.com, gdb-patches@sourceware.org, >> ktietz@redhat.com >> >> Note that set_gdbarch_infcall_mmap doesn't need to implement the >> whole feature set of mmap. We only need to be able to carve out a >> piece of memory. Should map trivially to VirtualAlloc. > > That's true, but if this feature will work by doing the equivalent of > dlopen, then it will most probably only ever work on GNU/Linux. Even > there, we cannot really hope to do all this stuff by hand, do it > safely, and then track all the changes in the OS to keep this working > for the years to come. And good luck being able to do it at all on > proprietary systems such as Windows, where you cannot simply examine > the sources of the DLL loader. I don't think we'll need to. In fact, I have a feeling that on Windows things will tend to be simpler, given PE is simpler/more contained than ELF. But if it turns out that whoever tries to make this work on Windows finds out that the LoadLibrary route is better for Windows, then I don't see that as a problem. I'm sure we can fit that in by overriding some hooks. > I conclude that sadly this feature is extremely limited, and will > probably die very soon, unless we change its implementation to > something more portable and safe. We shall see. :-) Thanks, Pedro Alves
--- ./gdb/compile/compile.c 2014-12-14 02:48:38.000000000 +0100 +++ ./gdb/compile/compile.c 2014-12-15 23:21:28.788716340 +0100 @@ -191,7 +191,11 @@ get_compile_file_tempdir (void) strcpy (tname, TEMPLATE); #undef TEMPLATE +#ifdef _WIN32 + error (_("mkdtemp needs to be implemented for MS-Windows hosts")); +#else tempdir_name = mkdtemp (tname); +#endif if (tempdir_name == NULL) perror_with_name (_("Could not make temporary directory"));