* assert does not show output in cygwin test build @ 2019-10-09 7:16 Biswapriyo Nath 2019-10-09 10:03 ` Takashi Yano 2019-10-09 15:31 ` assert creates unusable core dump on current stable Cygwin release Brian Inglis 0 siblings, 2 replies; 14+ messages in thread From: Biswapriyo Nath @ 2019-10-09 7:16 UTC (permalink / raw) To: cygwin * mintty version: mintty 3.0.6 (x86_64-pc-cygwin) * cygwin version: 3.1.0-0.6 * code: #include <assert.h> int main() { int x = 1; assert(x == 0); } * Expected result: The terminal should show this message which appers in latest stable cygwin version. assertion "x == 0" failed: file "test.c", line 6, function: main * Actual result: terminal only shows "Aborted (core dumped)". -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: assert does not show output in cygwin test build 2019-10-09 7:16 assert does not show output in cygwin test build Biswapriyo Nath @ 2019-10-09 10:03 ` Takashi Yano 2019-10-09 10:39 ` Pavel Fedin 2019-10-09 15:31 ` assert creates unusable core dump on current stable Cygwin release Brian Inglis 1 sibling, 1 reply; 14+ messages in thread From: Takashi Yano @ 2019-10-09 10:03 UTC (permalink / raw) To: cygwin On Wed, 9 Oct 2019 12:44:14 +0530 Biswapriyo Nath wrote: > * mintty version: mintty 3.0.6 (x86_64-pc-cygwin) > * cygwin version: 3.1.0-0.6 > * code: > > #include <assert.h> > > int main() { > int x = 1; > assert(x == 0); > } > > * Expected result: The terminal should show this message which appers > in latest stable cygwin version. > assertion "x == 0" failed: file "test.c", line 6, function: main > > * Actual result: terminal only shows "Aborted (core dumped)". Thanks for your report. However, I cannot reproduce the problem. 1. Could you please describe the steps to reproduce this? 2. What happens if you execute: ./a.exe 2>&1 | cat -- Takashi Yano <takashi.yano@nifty.ne.jp> -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: assert does not show output in cygwin test build 2019-10-09 10:03 ` Takashi Yano @ 2019-10-09 10:39 ` Pavel Fedin 2019-10-09 10:54 ` Takashi Yano 0 siblings, 1 reply; 14+ messages in thread From: Pavel Fedin @ 2019-10-09 10:39 UTC (permalink / raw) To: 'Takashi Yano', cygwin Hello! > Thanks for your report. However, I cannot reproduce the problem. > > 1. Could you please describe the steps to reproduce this? g++ test.cpp -o test ./test > 2. What happens if you execute: > ./a.exe 2>&1 | cat The same. No output. From gdb i know that the control reaches __cxa_throw and then RaiseException(). Then the app apparently just exits. I'll try to debug this myself when i have some time. Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: assert does not show output in cygwin test build 2019-10-09 10:39 ` Pavel Fedin @ 2019-10-09 10:54 ` Takashi Yano 2019-10-09 11:27 ` Pavel Fedin 0 siblings, 1 reply; 14+ messages in thread From: Takashi Yano @ 2019-10-09 10:54 UTC (permalink / raw) To: cygwin On Wed, 9 Oct 2019 13:39:42 +0300 "Pavel Fedin" wrote: > Hello! > > > Thanks for your report. However, I cannot reproduce the problem. > > > > 1. Could you please describe the steps to reproduce this? > > g++ test.cpp -o test > ./test > > > 2. What happens if you execute: > > ./a.exe 2>&1 | cat > > The same. No output. > From gdb i know that the control reaches __cxa_throw and then RaiseException(). Then the app apparently just exits. > > I'll try to debug this myself when i have some time. Is this surely the reply to "Re: assert does not show output in cygwin test build" ? Or your reply is regarding "Cygwin and stdexcept bug ?" ? -- Takashi Yano <takashi.yano@nifty.ne.jp> -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: assert does not show output in cygwin test build 2019-10-09 10:54 ` Takashi Yano @ 2019-10-09 11:27 ` Pavel Fedin 2019-10-09 12:39 ` Biswapriyo Nath 0 siblings, 1 reply; 14+ messages in thread From: Pavel Fedin @ 2019-10-09 11:27 UTC (permalink / raw) To: 'Takashi Yano', cygwin > Is this surely the reply to "Re: assert does not show output in > cygwin test build" ? > > Or your reply is regarding "Cygwin and stdexcept bug ?" ? Ops, sorry, messed up. :) The latter of course. Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: assert does not show output in cygwin test build 2019-10-09 11:27 ` Pavel Fedin @ 2019-10-09 12:39 ` Biswapriyo Nath 0 siblings, 0 replies; 14+ messages in thread From: Biswapriyo Nath @ 2019-10-09 12:39 UTC (permalink / raw) To: cygwin From Takashi Yano's query, I ran those command, the last one shows the assertion output. But wait! I rename the home folder (~) in cygwin then revert it back. Now there is no issue. Don't know what happened. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: assert creates unusable core dump on current stable Cygwin release 2019-10-09 7:16 assert does not show output in cygwin test build Biswapriyo Nath 2019-10-09 10:03 ` Takashi Yano @ 2019-10-09 15:31 ` Brian Inglis 2019-10-09 17:10 ` Jon Turney 1 sibling, 1 reply; 14+ messages in thread From: Brian Inglis @ 2019-10-09 15:31 UTC (permalink / raw) To: cygwin On 2019-10-09 01:14, Biswapriyo Nath wrote: > * mintty version: mintty 3.0.6 (x86_64-pc-cygwin) > * cygwin version: 3.1.0-0.6 > * code: > > #include <assert.h> > > int main() { > int x = 1; > assert(x == 0); > } > > * Expected result: The terminal should show this message which appers > in latest stable cygwin version. > assertion "x == 0" failed: file "test.c", line 6, function: main > > * Actual result: terminal only shows "Aborted (core dumped)". I also get the core dump, which is un-gdb-able below, as is it's core dump, on *current stable* Cygwin 64 releases *AND* see the message! $ gcc -g -Og -Wall -Wextra -o t t.c $ ./t assertion "x == 0" failed: file "t.c", line 5, function: main *** starting debugger for pid 52441, tid 15616 *** continuing pid 52441 from debugger call (1) Aborted (core dumped) $ gdb ./t.exe ./t.exe.core GNU gdb (GDB) (Cygwin 8.1.1-1) 8.1.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-cygwin". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./t.exe...done. warning: core file may not match specified executable file. [New Thread 0x3df4] [New Thread 0x6850] [New Thread 0x56dc] [New Thread 0xf854] [New Thread 0xd3cc] [New Thread 0xbda8] warning: Unexpected size of section `.reg/15860' in core file. /wip/cygport-git/gdb/gdb-8.1.1-1.x86_64/src/gdb-8.1.1/gdb/corelow.c:548: internal-error: void get_core_register_section(regcache*, const regset*, const char*, int, int, const char*, int): Assertion `core_vec' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) y This is a bug, please report it. For instructions, see: <http://www.gnu.org/software/gdb/bugs/>. /wip/cygport-git/gdb/gdb-8.1.1-1.x86_64/src/gdb-8.1.1/gdb/corelow.c:548: internal-error: void get_core_register_section(regcache*, const regset*, const char*, int, int, const char*, int): Assertion `core_vec' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) n $ gdb ./t GNU gdb (GDB) (Cygwin 8.1.1-1) 8.1.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-cygwin". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./t...done. (gdb) run Starting program: /home/bwi/src/t [New Thread 40060.0x1073c] [New Thread 40060.0x2df0] [New Thread 40060.0x49b4] [New Thread 40060.0x12b8] assertion "x == 0" failed: file "t.c", line 5, function: main Thread 1 "t" received signal SIGABRT, Aborted. 0x00000000ffffe458 in ?? () (gdb) bt #0 0x00000000ffffe458 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) q A debugging session is active. Inferior 1 [process 40060] will be killed. Quit anyway? (y or n) y $ uname -srvmo CYGWIN_NT-10.0 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64 Cygwin $ head /proc/version CYGWIN_NT-10.0-17763 version 3.0.7-338.x86_64 (corinna@calimero) (gcc version 7.4.0 20181206 (Fedora Cygwin 7.4.0-1) (GCC) ) 2019-04-30 18:08 UTC $ gcc --version gcc (GCC) 7.4.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: assert creates unusable core dump on current stable Cygwin release 2019-10-09 15:31 ` assert creates unusable core dump on current stable Cygwin release Brian Inglis @ 2019-10-09 17:10 ` Jon Turney 2019-10-09 21:28 ` Brian Inglis 0 siblings, 1 reply; 14+ messages in thread From: Jon Turney @ 2019-10-09 17:10 UTC (permalink / raw) To: The Cygwin Mailing List; +Cc: Brian.Inglis On 09/10/2019 16:31, Brian Inglis wrote: > On 2019-10-09 01:14, Biswapriyo Nath wrote: >> * mintty version: mintty 3.0.6 (x86_64-pc-cygwin) >> * cygwin version: 3.1.0-0.6 >> * code: >> >> #include <assert.h> >> >> int main() { >> int x = 1; >> assert(x == 0); >> } >> >> * Expected result: The terminal should show this message which appers >> in latest stable cygwin version. >> assertion "x == 0" failed: file "test.c", line 6, function: main >> >> * Actual result: terminal only shows "Aborted (core dumped)". > > I also get the core dump, which is un-gdb-able below, as is it's core dump, on > *current stable* Cygwin 64 releases *AND* see the message! As far as I'm aware, the core-dump tool 'dumper' has never been fixed for x86_64, so I wouldn't expect this to work. See [1]. [1] https://cygwin.com/ml/cygwin/2016-03/msg00464.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: assert creates unusable core dump on current stable Cygwin release 2019-10-09 17:10 ` Jon Turney @ 2019-10-09 21:28 ` Brian Inglis 2019-10-10 19:19 ` Jon Turney 0 siblings, 1 reply; 14+ messages in thread From: Brian Inglis @ 2019-10-09 21:28 UTC (permalink / raw) To: The Cygwin Mailing List On 2019-10-09 11:10, Jon Turney wrote: > On 09/10/2019 16:31, Brian Inglis wrote: >> On 2019-10-09 01:14, Biswapriyo Nath wrote: >>> * mintty version: mintty 3.0.6 (x86_64-pc-cygwin) * cygwin version: >>> 3.1.0-0.6 * code: >>> >>> #include <assert.h> >>> >>> int main() { int x = 1; assert(x == 0); } >>> >>> * Expected result: The terminal should show this message which appers in >>> latest stable cygwin version. assertion "x == 0" failed: file "test.c", >>> line 6, function: main >>> >>> * Actual result: terminal only shows "Aborted (core dumped)". >> >> I also get the core dump, which is un-gdb-able below, as is it's core dump, >> on *current stable* Cygwin 64 releases *AND* see the message! > > As far as I'm aware, the core-dump tool 'dumper' has never been fixed for > x86_64, so I wouldn't expect this to work. See [1]. > > [1] https://cygwin.com/ml/cygwin/2016-03/msg00464.html Given that it's used elsewhere, is there more to it than just: int dumper::init_core_dump () { bfd_init (); - core_bfd = bfd_openw (file_name, "elf32-i386"); + core_bfd = bfd_openw (file_name, "elf64-x86"); if (core_bfd == NULL) { bfd_perror ("opening bfd"); goto failed; } if (!bfd_set_format (core_bfd, bfd_core)) { bfd_perror ("setting bfd format"); goto failed; } - if (!bfd_set_arch_mach (core_bfd, bfd_arch_i386, 0)) + if (!bfd_set_arch_mach (core_bfd, bfd_arch_i386, bfd_mach_x86_64)) { bfd_perror ("setting bfd architecture"); goto failed; } return 1; failed: dumper_abort (); return 0; } -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: assert creates unusable core dump on current stable Cygwin release 2019-10-09 21:28 ` Brian Inglis @ 2019-10-10 19:19 ` Jon Turney 2019-10-10 20:57 ` Csaba Raduly 0 siblings, 1 reply; 14+ messages in thread From: Jon Turney @ 2019-10-10 19:19 UTC (permalink / raw) To: The Cygwin Mailing List; +Cc: Brian.Inglis On 09/10/2019 22:28, Brian Inglis wrote: > On 2019-10-09 11:10, Jon Turney wrote: >> On 09/10/2019 16:31, Brian Inglis wrote: >>> On 2019-10-09 01:14, Biswapriyo Nath wrote: >>>> * mintty version: mintty 3.0.6 (x86_64-pc-cygwin) * cygwin version: >>>> 3.1.0-0.6 * code: >>>> >>>> #include <assert.h> >>>> >>>> int main() { int x = 1; assert(x == 0); } >>>> >>>> * Expected result: The terminal should show this message which appers in >>>> latest stable cygwin version. assertion "x == 0" failed: file "test.c", >>>> line 6, function: main >>>> >>>> * Actual result: terminal only shows "Aborted (core dumped)". >>> >>> I also get the core dump, which is un-gdb-able below, as is it's core dump, >>> on *current stable* Cygwin 64 releases *AND* see the message! >> >> As far as I'm aware, the core-dump tool 'dumper' has never been fixed for >> x86_64, so I wouldn't expect this to work. See [1]. >> >> [1] https://cygwin.com/ml/cygwin/2016-03/msg00464.html > > Given that it's used elsewhere, is there more to it than just: Not sure what you are referring to by 'it', don't know where you mean by 'elsewhere'. > int > dumper::init_core_dump () > { > bfd_init (); > > - core_bfd = bfd_openw (file_name, "elf32-i386"); > + core_bfd = bfd_openw (file_name, "elf64-x86"); idk, have you tried it? If I recall correctly, there's some code in gdb to handle these strange "'core dump'" files, which might well also need some attention for the x86_64 case. (and I guess this patch is not acceptable as-is, as it looks like it would break x86) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: assert creates unusable core dump on current stable Cygwin release 2019-10-10 19:19 ` Jon Turney @ 2019-10-10 20:57 ` Csaba Raduly 2019-10-10 22:20 ` Brian Inglis 0 siblings, 1 reply; 14+ messages in thread From: Csaba Raduly @ 2019-10-10 20:57 UTC (permalink / raw) To: cygwin list On Thu, Oct 10, 2019 at 9:19 PM Jon Turney wrote: > (and I guess this patch is not acceptable as-is, as it looks like it > would break x86) That was my reaction too. Csaba -- You can get very substantial performance improvements by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler So if you're looking for a completely portable, 100% standards-conformant way to get the wrong information: this is what you want. - Scott Meyers (C++TDaWYK) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: assert creates unusable core dump on current stable Cygwin release 2019-10-10 20:57 ` Csaba Raduly @ 2019-10-10 22:20 ` Brian Inglis 2019-10-13 16:27 ` Jon Turney 0 siblings, 1 reply; 14+ messages in thread From: Brian Inglis @ 2019-10-10 22:20 UTC (permalink / raw) To: cygwin On 2019-10-10 14:57, Csaba Raduly wrote: > On Thu, Oct 10, 2019 at 9:19 PM Jon Turney wrote: >> (and I guess this patch is not acceptable as-is, as it looks like it >> would break x86) > That was my reaction too. Obviously there would have to be some arch dependent conditional changes, but I was hoping that someone with a clue about libbfd, could provide some hints as to where else to look for more info on what other changes might be required, or confirmation that this is object oriented enough to mainly just work with some additional tweaks. I also found out, and found a mailing list post that confirmed, that gdb gcore also does not work to generate a core image on Windows, as that was my next place to look. So it looks like gdb gcore for x86 could be implemented by adding the dumper code. The question is where to ask or look to figure out what Windows x86_64 needs over what Windows x86 needs, and add that to both gdb gcore and dumper, as gdb seems to handle debugging and debuginfo fine. If this could be derived from say, Cygwin ld libbfd calls, or the diffs between x86 and x86_64 ld.bfd calls, or nm, objcopy, objdump etc. diffs, I could look at doing that. I'm not sure I'd want to have to understand in detail how Windows puts its exes together to get started. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: assert creates unusable core dump on current stable Cygwin release 2019-10-10 22:20 ` Brian Inglis @ 2019-10-13 16:27 ` Jon Turney 2019-10-13 18:14 ` Brian Inglis 0 siblings, 1 reply; 14+ messages in thread From: Jon Turney @ 2019-10-13 16:27 UTC (permalink / raw) To: The Cygwin Mailing List; +Cc: Brian.Inglis On 10/10/2019 23:20, Brian Inglis wrote: > On 2019-10-10 14:57, Csaba Raduly wrote: >> On Thu, Oct 10, 2019 at 9:19 PM Jon Turney wrote: >>> (and I guess this patch is not acceptable as-is, as it looks like it >>> would break x86) >> That was my reaction too. > > Obviously there would have to be some arch dependent conditional changes, but I You could do that. Then at least we'd have something to test. It might even 'just work'. > was hoping that someone with a clue about libbfd, could provide some hints as to > where else to look for more info on what other changes might be required, or > confirmation that this is object oriented enough to mainly just work with some > additional tweaks. I don't think the person who has an in-depth knowledge of bfd and is interested in this issue exists. FWIW, as I wrote previously, the difficulties I would anticipate would be in the direction of size differences in the thread status information etc., rather than using bfd to write the memory image. > I also found out, and found a mailing list post that confirmed, that gdb gcore > also does not work to generate a core image on Windows, as that was my next > place to look. Again, there's no such thing as a "Windows core file" (*) There's this special thing that Cygwin's dumper writes which is an ELF container for the process memory image, with NT_WIN32PSTATUS ELF notes which contain Win32 API thread status structures. (*) well, there are Windows minidumps, and it would perhaps be conceptually simpler if this was implemented using those, but getting gdb to read those would be a major project. > So it looks like gdb gcore for x86 could be implemented by adding the dumper code. Yes. I'm not sure that adds a huge amount of value, though, as we already have a working dumper for x86. > The question is where to ask or look to figure out what Windows x86_64 needs > over what Windows x86 needs, and add that to both gdb gcore and dumper, as gdb > seems to handle debugging and debuginfo fine. You can ask here, or on the cygwin-developers list, or on IRC. But if you're just asking questions, with no intention of actually doing the work, that would just be a waste of everyone's time. :) I'd suggest you start by looking at elfcore_grok_win32pstatus() in libbfd, and comparing that with the ELF notes that dumper.cc writes, also specifically looking for assumptions about sizes which might be different for x86 and x86_64. Next you'd want to look at i386-cygwin-tdep.c in gdb, and how that handles the '.reg' and '.module' pseudo-sections that are created by that when reading the core dump. > If this could be derived from say, Cygwin ld libbfd calls, or the diffs between > x86 and x86_64 ld.bfd calls, or nm, objcopy, objdump etc. diffs, I could look at > doing that. > I'm not sure I'd want to have to understand in detail how Windows puts its exes > together to get started. I don't think any knowledge of PE/COFF executables is needed to do this work (since, again, the "core dump" uses a ELF container). -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: assert creates unusable core dump on current stable Cygwin release 2019-10-13 16:27 ` Jon Turney @ 2019-10-13 18:14 ` Brian Inglis 0 siblings, 0 replies; 14+ messages in thread From: Brian Inglis @ 2019-10-13 18:14 UTC (permalink / raw) To: The Cygwin Mailing List On 2019-10-13 10:27, Jon Turney wrote: > On 10/10/2019 23:20, Brian Inglis wrote: >> On 2019-10-10 14:57, Csaba Raduly wrote: >>> On Thu, Oct 10, 2019 at 9:19 PM Jon Turney wrote: >>>> (and I guess this patch is not acceptable as-is, as it looks like it >>>> would break x86) >>> That was my reaction too. >> >> Obviously there would have to be some arch dependent conditional changes, but I > > You could do that. Then at least we'd have something to test. It might even > 'just work'. > >> was hoping that someone with a clue about libbfd, could provide some hints as to >> where else to look for more info on what other changes might be required, or >> confirmation that this is object oriented enough to mainly just work with some >> additional tweaks. > > I don't think the person who has an in-depth knowledge of bfd and is interested > in this issue exists. > > FWIW, as I wrote previously, the difficulties I would anticipate would be in the > direction of size differences in the thread status information etc., rather than > using bfd to write the memory image. > >> I also found out, and found a mailing list post that confirmed, that gdb gcore >> also does not work to generate a core image on Windows, as that was my next >> place to look. > > Again, there's no such thing as a "Windows core file" (*) > > There's this special thing that Cygwin's dumper writes which is an ELF container > for the process memory image, with NT_WIN32PSTATUS ELF notes which contain Win32 > API thread status structures. > > (*) well, there are Windows minidumps, and it would perhaps be conceptually > simpler if this was implemented using those, but getting gdb to read those would > be a major project. > >> So it looks like gdb gcore for x86 could be implemented by adding the dumper >> code. > > Yes. I'm not sure that adds a huge amount of value, though, as we already have > a working dumper for x86. Yes, but we don't have that yet in GDB, although GDB understands both x86 and x86_64 in memory exe formats, so if we added gcore to x86 GDB, we should be able to adapt that for x86_64, then apply analogous x86_64 dumper changes based on the gcore changes, as presumably they are all based around libbfd. >> The question is where to ask or look to figure out what Windows x86_64 needs >> over what Windows x86 needs, and add that to both gdb gcore and dumper, as gdb >> seems to handle debugging and debuginfo fine. > > You can ask here, or on the cygwin-developers list, or on IRC. > > But if you're just asking questions, with no intention of actually doing the > work, that would just be a waste of everyone's time. :) We're in a catch-22, as we need enough info to think the work can be completed successfully with a reasonable amount of effort and time. I've wasted time before doing bunches of R never getting to D! ;^> My concerns are around hearing that Win64 exes are a totally different format in a PE wrapper; on the other hand, Cygwin GDB can load, run, debug them okay, so libbfd must work somewhat compatibly, but if it was easy, it would have been done, so we need some basis for how to do it and how long it will take. > I'd suggest you start by looking at elfcore_grok_win32pstatus() in libbfd, and > comparing that with the ELF notes that dumper.cc writes, also specifically > looking for assumptions about sizes which might be different for x86 and x86_64. > > Next you'd want to look at i386-cygwin-tdep.c in gdb, and how that handles the > '.reg' and '.module' pseudo-sections that are created by that when reading the > core dump. Thanks, will look at GDB, binutils, libbfd, dumper, and arch source differences late next week, as I have some commitments. Any idea why libbfd is not a separate package under Cygwin, like other distros, but presumably part of both binutils and gdb? >> If this could be derived from say, Cygwin ld libbfd calls, or the diffs between >> x86 and x86_64 ld.bfd calls, or nm, objcopy, objdump etc. diffs, I could look at >> doing that. >> I'm not sure I'd want to have to understand in detail how Windows puts its exes >> together to get started. > > I don't think any knowledge of PE/COFF executables is needed to do this work > (since, again, the "core dump" uses a ELF container). But presumably that PE/COFF in-memory executable format has to be picked apart, and that has already been done to allow GDB to work with it, then written into that ELF container, and that part has not been done yet, so should be less than trivial or blindingly obvious. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2019-10-13 18:14 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-10-09 7:16 assert does not show output in cygwin test build Biswapriyo Nath 2019-10-09 10:03 ` Takashi Yano 2019-10-09 10:39 ` Pavel Fedin 2019-10-09 10:54 ` Takashi Yano 2019-10-09 11:27 ` Pavel Fedin 2019-10-09 12:39 ` Biswapriyo Nath 2019-10-09 15:31 ` assert creates unusable core dump on current stable Cygwin release Brian Inglis 2019-10-09 17:10 ` Jon Turney 2019-10-09 21:28 ` Brian Inglis 2019-10-10 19:19 ` Jon Turney 2019-10-10 20:57 ` Csaba Raduly 2019-10-10 22:20 ` Brian Inglis 2019-10-13 16:27 ` Jon Turney 2019-10-13 18:14 ` Brian Inglis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).