|
From: | Vincent Torri |
Subject: | Re: [Libunwind-devel] using libunwind on Windows |
Date: | Wed, 16 Mar 2016 08:52:44 +0100 |
just fyi, the output of configure on Windows, in case you see something that can help meVincentOn Wed, Mar 16, 2016 at 8:40 AM, Vincent Torri <address@hidden> wrote:Vincentif 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 anymoreso 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 leastOn 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
> https://lists.nongnu.org/mailman/listinfo/libunwind-devel
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
libunwind_win32_1.diff
Description: Text document
[Prev in Thread] | Current Thread | [Next in Thread] |