libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] using libunwind on Windows


From: Vincent Torri
Subject: Re: [Libunwind-devel] using libunwind on Windows
Date: Wed, 16 Mar 2016 08:52:44 +0100

and for the record the (for now ?) useless infra i have written. As you can see, nothing is done as libunwind_la_SOURCES_os_win32 is empty.

On Wed, Mar 16, 2016 at 8:44 AM, Vincent Torri <address@hidden> wrote:
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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden
>> <mailto:address@hidden>> 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
>>     address@hidden <mailto:address@hidden>
>>
>>     _______________________________________________
>>     Libunwind-devel mailing list
>>     address@hidden <mailto:address@hidden>
>>     https://lists.nongnu.org/mailman/listinfo/libunwind-devel
>>
>>
>
> _______________________________________________
> Libunwind-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/libunwind-devel



Attachment: libunwind_win32_1.diff
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]