just fyi, the output of configure on Windows, in case you see something
that can help me

Vincent

On Wed, Mar 16, 2016 at 8:40 AM, Vincent Torri <[email protected]>
wrote:

> if you look at the patch :
>
> 1) unwind.h : there is no more #ifdef __LP64__
> 2) AddressSpace.hpp, UnwindLevel1-gcc-ext.c and assembly.h do not exist
> anymore
>
> so i doubt that there is any interest in trying to apply the patch.
>
> i'm very interested in adding windows support, but i have to understabd
> the libunwind internal first. The i have to write some os-win32.c at least
>
> Vincent
>
>
>
> On Wed, Mar 16, 2016 at 8:22 AM, C Bergström <[email protected]>
> wrote:
>
>> I don't have any Windows engineers to update this patch, but if
>> there's anyone who would rebase it for some bounty let me know. I'd
>> love to see some level of Win support available.
>>
>> Thanks
>>
>> On Wed, Mar 16, 2016 at 3:17 PM, Martin Hundebøll <[email protected]>
>> wrote:
>> > Hi Vincet,
>> >
>> > Thanks for taking the time to consider this. Guess I'll just disable out
>> > libunwind in our mingw build.
>> >
>> > // Martin
>> >
>> > On 2016-03-16 07:35, Vincent Torri wrote:
>> >>
>> >> Hello
>> >>
>> >> unfortunately, this patch can not apply anymore, due to internal
>> changes
>> >> in libunwind.
>> >>
>> >> also, i've seen some use of the long type (in unwind.h for example),
>> >> which is always 32 bits long on Windows, even on Windows 64 bit. I
>> don't
>> >> know if it is a problem or not
>> >>
>> >> Also, now, in src/ there are some OS specific files (about shared mem
>> >> and ELF). There are shared mem API on Windows, but i don't know what i
>> >> would do with ELF stuff...
>> >>
>> >> I have added some infra in the autotools for Windows, but with no
>> >> windows source code, it's a bit useless...
>> >>
>> >> Vincent Torri
>> >>
>> >>
>> >> On Tue, Mar 15, 2016 at 9:44 PM, Martin Hundebøll <
>> [email protected]
>> >> <mailto:[email protected]>> wrote:
>> >>
>> >>     Hi Vincent / libunwind dev
>> >>
>> >>     I came across this patch and I propose it being included in
>> upstream
>> >>     libunwind:
>> >>
>> >>
>> https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-libunwind-svn/0001-libunwind-add-support-for-mingw-w64.patch
>> >>
>> >>     Thanks,
>> >>     Martin
>> >>
>> >>
>> >>     On 2015-12-13 09:29, Vincent Torri wrote:
>> >>
>> >>         Hello
>> >>
>> >>         I am writing a small valgrind-like program on Windows, to
>> detect
>> >>         memleak and some errors that valgrind's memcheck identifies.
>> >>
>> >>         Currently, for the backtrace, I use the Windows API if compiled
>> >> with
>> >>         vc++, and libbfd if compiled with gcc (mingw-w64). libbfd works
>> >> well
>> >>         (i get file, function ad line number that I want), but the
>> >>         licence is
>> >>         a problem (GPL v3).
>> >>
>> >>         libdwarf seems big, libunwind seems smaller, and according to
>> the
>> >>         documentation, libunwind can manage DWARF format
>> >>
>> >>         If I'm not mistaken, the GNU linker provides debugging
>> >>         informations in
>> >>         the DWARF format on Windows.
>> >>
>> >>         I have 2 questions:
>> >>
>> >>         1) Do you think that libunwind could indeed provide backtrace
>> from
>> >>         programs/libraries linked with the GNU linker on Windows ?
>> >>
>> >>         2) if yes, as i am quite interested to have libunwind on
>> Windows,
>> >>         compiling it with MSYS/mingw-w64 (not vc++), where should I
>> >>         start, and
>> >>         which files should I look first ?
>> >>
>> >>         Note that I would like to provide patches upstream, not to fork
>> >>         libunwind.
>> >>
>> >>         thank you
>> >>
>> >>         Vincent Torri
>> >>
>> >>
>> >>
>> >>
>> >>     --
>> >>     Kind Regards,
>> >>     Martin Hundebøll
>> >>     Kildeagervej 166
>> >>     8361 Hasselager
>> >>
>> >>     +45 25 56 24 38
>> >>     [email protected] <mailto:[email protected]>
>> >>
>> >>     _______________________________________________
>> >>     Libunwind-devel mailing list
>> >>     [email protected] <mailto:[email protected]>
>> >>     https://lists.nongnu.org/mailman/listinfo/libunwind-devel
>> >>
>> >>
>> >
>> > _______________________________________________
>> > Libunwind-devel mailing list
>> > [email protected]
>> > https://lists.nongnu.org/mailman/listinfo/libunwind-devel
>>
>
>

Attachment: configure.output
Description: Binary data

_______________________________________________
Libunwind-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/libunwind-devel

Reply via email to