assert does not show output in cygwin test build

assert does not show output in cygwin test build

[Biswapriyo Nath]

* 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

Re: assert does not show output in cygwin test build

[Takashi Yano]

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

RE: assert does not show output in cygwin test build

[Pavel Fedin]

 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

Re: assert does not show output in cygwin test build

[Takashi Yano]

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

RE: assert does not show output in cygwin test build

[Pavel Fedin]

> 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

Re: assert does not show output in cygwin test build

[Biswapriyo Nath]

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

Re: assert creates unusable core dump on current stable Cygwin release

[Brian Inglis]

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

Re: assert creates unusable core dump on current stable Cygwin release

[Jon Turney]

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

Re: assert creates unusable core dump on current stable Cygwin release

[Brian Inglis]

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

Re: assert creates unusable core dump on current stable Cygwin release

[Jon Turney]

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

Re: assert creates unusable core dump on current stable Cygwin release

[Csaba Raduly]

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

Re: assert creates unusable core dump on current stable Cygwin release

[Brian Inglis]

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

Re: assert creates unusable core dump on current stable Cygwin release

[Jon Turney]

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

Re: assert creates unusable core dump on current stable Cygwin release

[Brian Inglis]

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