Alistair Leslie-Hughes writes:
> @@ -1717,6 +1717,17 @@ BOOL WINAPI SymGetLineNext64(HANDLE hProcess,
> PIMAGEHLP_LINE64 Line)
> }
>
> /**
> + * SymGetLineNextW64 (DBGHELP.@)
> + *
Am 22.01.2013 20:26, schrieb Eric Pouech:
> Le 21/01/2013 20:26, André Hentschel a écrit :
>> Am 21.01.2013 10:50, schrieb Eric Pouech:
+if ((frame->AddrPC.Mode == AddrModeFlat) &&
+(frame->AddrFrame.Mode != AddrModeFlat))
>>> this looks strange to me.
>>> I guess, you
Le 21/01/2013 20:26, André Hentschel a écrit :
Am 21.01.2013 10:50, schrieb Eric Pouech:
+if ((frame->AddrPC.Mode == AddrModeFlat) &&
+(frame->AddrFrame.Mode != AddrModeFlat))
this looks strange to me.
I guess, you want to check that both mode address modes are AddrModeFlat
Am 21.01.2013 10:50, schrieb Eric Pouech:
>> +if ((frame->AddrPC.Mode == AddrModeFlat) &&
>> +(frame->AddrFrame.Mode != AddrModeFlat))
> this looks strange to me.
> I guess, you want to check that both mode address modes are AddrModeFlat
> A+
>
it's the same as for the other a
> +if ((frame->AddrPC.Mode == AddrModeFlat) &&
> +(frame->AddrFrame.Mode != AddrModeFlat))
this looks strange to me.
I guess, you want to check that both mode address modes are AddrModeFlat
A+
--
Eric Pouech
The A version should call the W one, not the other way around.
Alexandre,
in order to properly manage this, we need to move file names in dbghelp
from ansi to unicode
but, as dbghelp API uses some kind of regular expression to match
filenames, we need a unicode regex function set
Eric Pouech writes:
>> The A version should call the W one, not the other way around.
> Alexandre,
>
> in order to properly manage this, we need to move file names in
> dbghelp from ansi to unicode
> but, as dbghelp API uses some kind of regular expression to match
> file
Andrew Nguyen writes:
> This fixes bug 27222.
>
> ---
> dlls/dbghelp/dbghelp.spec |2 +-
> dlls/dbghelp/source.c | 102
> +
> 2 files changed, 103 insertions(+), 1 deletions(-)
The A version should call the W one, not
Le 11/04/2011 19:07, Austin English a écrit :
IMO, you should keep the variable names in comment so that we know what
we're talking about:
/* version = */ dwarf2_parse_u2(&ctx);
or
dwarf2_parse_u2(&ctx); /* version */
A+
--
Eric Pouech
"The problem with designing something completely f
On Mon, Apr 11, 2011 at 01:08, Andrew Nguyen wrote:
> On 04/11/2011 12:41 AM, Austin English wrote:
>>
>
> This ignores the side effects of the dwarf2_parse_u2 function.
Nice catch, thanks. I'll send a fixed version.
--
-Austin
On 04/11/2011 12:41 AM, Austin English wrote:
>
This ignores the side effects of the dwarf2_parse_u2 function.
signature.asc
Description: OpenPGP digital signature
Le 28/08/2010 15:13, Andrew Talbot a écrit :
Hi,
Static functions pe_get_sect() and pe_get_sect_size() in dbghelp/pe_module.c
are not called. May I remove them or does anyone have plans for them?
Thanks,
Andy.
you can remove them. they have been superseeded by the ones in
Hi,
Static functions pe_get_sect() and pe_get_sect_size() in dbghelp/pe_module.c
are not called. May I remove them or does anyone have plans for them?
Thanks,
Andy.
checking for the DWARF version is
going to help -- do we want to abort for newer versions when these
actually should be compatible?)
Gerald
From: Gerald Pfeifer
Date: Sun, 2 May 2010 22:05:20
Subject: dbghelp: Remove two variables which are not really used in
dwarf2_parse_line_numbers.
--
Gerald Pfeifer a écrit :
ChangeLog:
Remove two variables which are not really used in
dwarf2_parse_line_numbers.
diff --git a/dlls/dbghelp/dwarf.c b/dlls/dbghelp/dwarf.c
index 4be0f6a..69d7357 100644
--- a/dlls/dbghelp/dwarf.c
+++ b/dlls/dbghelp/dwarf.c
@@ -1920,7 +1920,7 @@ static BOOL
Eric Pouech writes:
>> This breaks the non-ELF builds.
>>
>>
> where does it break ? about image_no_map not being defined, or
> something else ?
For that patch it's IMAGE_NO_MAP, but it looked like there were other
breakages in subsequent patches. I'd recommend setting up a MingW
cross-compil
Alexandre Julliard a écrit :
Eric Pouech writes:
- now exporting the file mapping facility to the debug info loader which need it
- allow to mark a section as to be kept (after debug info loading has been done)
This breaks the non-ELF builds.
where does it break ? about image_no_
Eric Pouech writes:
> - now exporting the file mapping facility to the debug info loader which need
> it
> - allow to mark a section as to be kept (after debug info loading has been
> done)
This breaks the non-ELF builds.
--
Alexandre Julliard
julli...@winehq.org
André Hentschel a écrit :
Eric Pouech schrieb:
André Hentschel a écrit :
thanks Eric Pouech for the reviews
---
dlls/dbghelp/dwarf.c | 229
+-
dlls/dbghelp/dwarf.h | 15
2 files changed, 204 insertions(+), 40 deletions(-)
diff
Eric Pouech schrieb:
> André Hentschel a écrit :
>> thanks Eric Pouech for the reviews
>> ---
>> dlls/dbghelp/dwarf.c | 229
>> +++++-
>> dlls/dbghelp/dwarf.h | 15
>> 2 files changed, 204 insertions(+),
André Hentschel a écrit :
thanks Eric Pouech for the reviews
---
dlls/dbghelp/dwarf.c | 229 +-
dlls/dbghelp/dwarf.h | 15
2 files changed, 204 insertions(+), 40 deletions(-)
diff --git a/dlls/dbghelp/dwarf.c b/dlls/dbghelp/dwarf.c
index
On Sat, Jan 2, 2010 at 7:20 AM, Eric Pouech wrote:
> Austin English a écrit :
>>
>> I noticed Microsoft's got dbghelp in a download available...would the
>> native dll be useful to anyone? E.g., should I add it to winetricks?
>>
>>
>> http://www.m
Austin English a écrit :
I noticed Microsoft's got dbghelp in a download available...would the
native dll be useful to anyone? E.g., should I add it to winetricks?
http://www.microsoft.com/downloads/details.aspx?FamilyID=cd1fc4b2-0885-47f4-af45-7fd5e14db6c0&DisplayLang=en
--
-Austin
Hi Austin,
Austin English schreef:
I noticed Microsoft's got dbghelp in a download available...would the
native dll be useful to anyone? E.g., should I add it to winetricks?
http://www.microsoft.com/downloads/details.aspx?FamilyID=cd1fc4b2-0885-47f4-af45-7fd5e14db6c0&Displ
I noticed Microsoft's got dbghelp in a download available...would the
native dll be useful to anyone? E.g., should I add it to winetricks?
http://www.microsoft.com/downloads/details.aspx?FamilyID=cd1fc4b2-0885-47f4-af45-7fd5e14db6c0&DisplayLang=en
--
-Austin
2009/12/29 Jason Green :
> Using "stg show" from stgit 0.14.2. Looks like that function is mostly just
> a passthrough to "git show". git-format-patch seems nicer since it gives
> the number of line items changed, etc., although there's probably an option
> in "git show" somewhere that will do th
On Dec 29, 2009, at 2:37 PM, Henri Verbeet wrote:
> 2009/12/29 Jason Green :
>> commit 317da09400946ca9f97361a47a227595c5bedfe3
>> Author: Eric van Beurden
>> Date: Tue Dec 29 12:35:03 2009 -0500
>>
>>Make sure the ClientPointers flag isn't set incorrectly
>
> Mostly out of curiosity, how
2009/12/29 Jason Green :
> commit 317da09400946ca9f97361a47a227595c5bedfe3
> Author: Eric van Beurden
> Date: Tue Dec 29 12:35:03 2009 -0500
>
> Make sure the ClientPointers flag isn't set incorrectly
Mostly out of curiosity, how did you generate this patch? That looks
like the kind of outp
Jason Green a écrit :
I don't think it's a good idea to change the exception structure passed
by the caller to the minidump creation
it's better to hard wire the optimization in dump_exception_info
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate
> dbghelp: Fixed arena allocation in pool_alloc.
Well, 'fixed' might be a wrong word, but this patch makes it more intuitive.
Jacek
Mike Ruprecht writes:
> diff --git a/dlls/dbghelp/module.c b/dlls/dbghelp/module.c
> index fcdea2e..4b6c3d6 100644
> --- a/dlls/dbghelp/module.c
> +++ b/dlls/dbghelp/module.c
> @@ -438,6 +438,7 @@ enum module_type module_get_type_by_name(const WCHAR*
> name)
&g
missing?
>>>
> [...]
>
>> 1,2) most of the dbghelp code will be of no use if no regex support is
>> present
>>
>
> It still feels wrong for Wine to fail compiling just because a regular
> expression library is missing. If we can compile Wine
On Sat, 13 Dec 2008, Eric Pouech wrote:
[...]
> > 1) #ifdef-out regexp support if regex.h is missing? Maybe with an
> > autoconf check for regcomp()?
> > 2) Add some reg*() stubs that do nothing if regex.h & co are missing?
[...]
> 1,2) most of the dbghelp code will
Francois Gouget a écrit :
> When I compile Wine with MinGW, the first error I get is in
> dlls/dbghelp/source.c. Yet it seems to me that there is no fundamental
> reason that would prevent dbghelp from working on Windows (i.e. it's not
> in the 'ntdll' category
When I compile Wine with MinGW, the first error I get is in
dlls/dbghelp/source.c. Yet it seems to me that there is no fundamental
reason that would prevent dbghelp from working on Windows (i.e. it's not
in the 'ntdll' category).
So the error is that although MinGW does not h
Eric Pouech wrote:
> however the last trace should be protected (and debugstr_a is a better
> choice than testing for a null string)
> A+
>
Thanks, Eric. I've sent a replacement patch (with a revised title).
--
Andy.
Andrew Talbot a écrit :
> Eric Pouech wrote:
>
>
>> looks like a bit strange to me that you get a null typename here
>> can you send me the DLL/.so file on which you get the seg fault
>> A+
>>
>>
>
> No known segfaults; I'm just doing static analysis. But
> stabs_pts_read_type_def() is call
Eric Pouech wrote:
> looks like a bit strange to me that you get a null typename here
> can you send me the DLL/.so file on which you get the seg fault
> A+
>
No known segfaults; I'm just doing static analysis. But
stabs_pts_read_type_def() is called several times within stabs.c passing
NULL as
Andrew Talbot a écrit :
> Changelog:
> dbghelp: Fix stabs_pts_read_type_def() for when typename is NULL.
>
> diff --git a/dlls/dbghelp/stabs.c b/dlls/dbghelp/stabs.c
> index d550633..3c69eec 100644
> --- a/dlls/dbghelp/stabs.c
> +++ b/dlls/dbghelp/stabs.c
> @@ -896,
Hi,
> should be:
> @ stdcall SymEnumerateSymbols64(long double ptr ptr)
Thanks, I missed that long long changed to double a while ago. I've re-sent the
patch.
Cheers,
Jon
Jon Griffiths a écrit :
> Hi,
>
> Title says it all.
>
> Cheers
> Jon
>
>
>
>
>
>
>
> -@ stub SymEnumerateSymbols64s
> +@ stdcall SymEnumerateSymbols64(long long long ptr ptr)
>
should be:
@ stdcall SymEnumerateSymbols
Dan Kegel a écrit :
> I'm now seeing some new valgrind warnings when
> wine is doing stack dumps after crashes:
>
> + Conditional jump or move depends on uninitialised value(s)
> +at dwarf2_load_one_entry (dwarf.c:983)
> +by dwarf2_lookup_type (dwarf.c:858)
> +by dwarf2_load_one_entr
I'm now seeing some new valgrind warnings when
wine is doing stack dumps after crashes:
+ Conditional jump or move depends on uninitialised value(s)
+at dwarf2_load_one_entry (dwarf.c:983)
+by dwarf2_lookup_type (dwarf.c:858)
+by dwarf2_load_one_entry (dwarf.c:1020)
+by dwarf2_
Jason Green a écrit :
> On Jan 23, 2008 3:38 PM, Eric Pouech <[EMAIL PROTECTED]> wrote:
>
>> Jason Green a écrit :
>> thanks for the sample files
>> how does this patch solve the issue ?
>> A+
>>
>> diff --git a/include/wine/mscvpdb.h b/include/wine/mscvpdb.h
>> index 58627c0..8a22dfd 100644
>>
On Jan 23, 2008 3:38 PM, Eric Pouech <[EMAIL PROTECTED]> wrote:
> Jason Green a écrit :
> thanks for the sample files
> how does this patch solve the issue ?
> A+
>
> diff --git a/include/wine/mscvpdb.h b/include/wine/mscvpdb.h
> index 58627c0..8a22dfd 100644
> --- a/include/wine/mscvpdb.h
> +++ b/
Jason Green a écrit :
thanks for the sample files
how does this patch solve the issue ?
A+
diff --git a/include/wine/mscvpdb.h b/include/wine/mscvpdb.h
index 58627c0..8a22dfd 100644
--- a/include/wine/mscvpdb.h
+++ b/include/wine/mscvpdb.h
@@ -343,9 +343,9 @@ union codeview_type
{
un
See the first paragraph: :)
Re-re-responses from Eric van Beurden. I'll send the sample app to
you off-list (and anyone else who wants a copy, just email me
directly).:
I'll send it to you off-list, too, John.
On Jan 23, 2008 10:31 AM, John Klehm <[EMAIL PROTECTED]> wrote:
> On Jan 23, 2008
On Jan 23, 2008 8:14 AM, Jason Green <[EMAIL PROTECTED]> wrote:
>
> The attached archive contains 4 files:
> - 'emptyTest.exe': the optimized release build executable linked to
> 'emptyTest.pdb'. This should crash.
> - 'emptyTest.pdb': the PDB file
> - 'main.cpp': the source file for the test app.
ng
> >> symbol should be fine is there an existing exe/pdb file available for
> >> further testings
> >>
> >
> >
> > in testing with one of our projects, i was seeing symbols lookups fail
> > 85-90% of the time with the initial versions of dbghelp. The
% of the time with the initial versions of dbghelp. The PDB
files that were being used were generated along with the release build
of the project (it was a C++ project as well). On further
investigation i found that the lookups were failing because many
symbol addresses and ranges were ove
the initial
> import of dbghelp instead of nice, incremental changes. I split
> things up based mostly on a file by file basis, but I can further
> split this one as well
>
> On Jan 18, 2008 3:14 PM, Eric Pouech <[EMAIL PROTECTED]> wrote:
>
>
>> what's the rat
Eric, below are the responses from Eric van Beurden, who wrote the
patch. I merely split it up and removed a bunch of traces for
submission to WineHQ. The problem is that all of our changes were
done initially in just a couple of huge commits during the initial
import of dbghelp instead of nice
H] Clamp minidump memory blocks to 928KB and improve TRACEs
> WinDbg can't read minidumps with memory blocks larger than this.
> From: Eric van Beurden ([EMAIL PROTECTED])
> ---
> dlls/dbghelp/minidump.c | 35 +--
> 1 files changed, 33 inserti
H] Fix file searching to search only listed directories instead
> of the whole HD.
> And, wrap some TRACE parameters in debugstr.
> From: Eric van Beurden ([EMAIL PROTECTED])
> ---
> dlls/dbghelp/path.c | 14 +++---
> 1 files changed, 7 insertions(+), 7 deletions(-)
&
Jason Green a écrit :
>
>
> From 14d91ebd5974c8fc02f8b83d53e8eff0df7ad76d Mon Sep 17 00:00:00 2001
> From: Jason Green <[EMAIL PROTECTED](none)>
> Date: Thu, 17 Jan 2008 16:41:11 -0500
> Subject: [PATCH] Rewrite much of the sy
"Jason Green" <[EMAIL PROTECTED]> writes:
> +
> +#ifdef TRACE_SYMBOL_LIST
> +TRACE("\n\n* sorting the table {count = %d}\n\n",
> module->num_sorttab);
> +#endif
> +
> +qsort(module->addr_sorttab, module->num_sorttab, sizeof(struct
> symbol_entry), symt_cmp_addr_and_size);
> +
> +
Eric Pouech <[EMAIL PROTECTED]> writes:
> - returning (instead of passing a pointer to) the size of the blocks pointed
> by the directories
> - now storing the PE version information in module blocks
> - fixed an un-initialized field in minidump header
> - fixed the suspend count value in thread
Alexandre Julliard wrote:
> Andrey Turkin <[EMAIL PROTECTED]> writes:
>
>
>> +if (image || addr < nt->OptionalHeader.SizeOfHeaders)
>> +{
>> +if (section)
>> +{
>> +PIMAGE_SECTION_HEADER sec = IMAGE_FIRST_SECTION(nt);
>> +WORD i;
>> +fo
Andrey Turkin <[EMAIL PROTECTED]> writes:
> +if (image || addr < nt->OptionalHeader.SizeOfHeaders)
> +{
> +if (section)
> +{
> +PIMAGE_SECTION_HEADER sec = IMAGE_FIRST_SECTION(nt);
> +WORD i;
> +for(i = 0; i < nt->FileHeader.NumberOfSecti
"Jason Green" <[EMAIL PROTECTED]> writes:
> The Original Author for the following set of patches is Eric van
> Beurden from TransGaming, Inc.
When submitting patches written by someone else please include a
valid From: line in the patch header with his full name and email.
--
Alexandre Julliard
"Jason Green" <[EMAIL PROTECTED]> writes:
> @@ -216,11 +216,17 @@ static BOOL WINAPI process_invade_cb(PCSTR name, ULONG
> base, ULONG size, PVOID u
> chartmp[MAX_PATH];
> HANDLE hProcess = (HANDLE)user;
>
> -if (!GetModuleFileNameExA(hProcess, (HMODULE)base,
> -
Markus Amsler a écrit :
Thanks to Eric for the idea.
---
dlls/dbghelp/dbghelp_private.h |3 +-
dlls/dbghelp/storage.c | 47
++-
2 files changed, 18 insertions(+), 32 deletions(-)
Markus, could you try what gives starting the bucket array size
On Mo, 2007-05-07 at 05:46 +0200, Markus Amsler wrote:
> +/* Don't even try to resize memory. Memory gain would be
> minimal
> + but speed hit significant with big vecotrs. *
I have no Idea about the code, but found this Typo:
vecotrs => vectors
--
By by ... Detle
Eric Pouech schrieb:
Markus Amsler a écrit :
No, performance is exactly the same as pool_heap :( .
even for memory consumption ???
Yes, it looks like HeapCreate has a default size of 64k.
I analyzed why your original insert_first version was slower and
memory hungrier then pool_heap. It turne
Markus Amsler a écrit :
Eric Pouech wrote:
Markus Amsler a écrit :
Eric Pouech wrote:
Markus Amsler a écrit :
I've played around with dbghelp performance. My test case was
breaking at an unknown symbol (break gaga) while WoW was loaded in
the debugger (wine winedbg WoW.exe). The tim
Eric Pouech wrote:
Markus Amsler a écrit :
Eric Pouech wrote:
Markus Amsler a écrit :
I've played around with dbghelp performance. My test case was
breaking at an unknown symbol (break gaga) while WoW was loaded in
the debugger (wine winedbg WoW.exe). The time was hand stopped,
memory
Markus Amsler a écrit :
Eric Pouech wrote:
Markus Amsler a écrit :
I've played around with dbghelp performance. My test case was
breaking at an unknown symbol (break gaga) while WoW was loaded in
the debugger (wine winedbg WoW.exe). The time was hand stopped,
memory usage measured wi
Eric Pouech wrote:
Markus Amsler a écrit :
I've played around with dbghelp performance. My test case was
breaking at an unknown symbol (break gaga) while WoW was loaded in
the debugger (wine winedbg WoW.exe). The time was hand stopped,
memory usage measured with ps -AF and looked at th
Markus Amsler a écrit :
I've played around with dbghelp performance. My test case was breaking
at an unknown symbol (break gaga) while WoW was loaded in the debugger
(wine winedbg WoW.exe). The time was hand stopped, memory usage
measured with ps -AF and looked at the RSS column.
I've played around with dbghelp performance. My test case was breaking
at an unknown symbol (break gaga) while WoW was loaded in the debugger
(wine winedbg WoW.exe). The time was hand stopped, memory usage measured
with ps -AF and looked at the RSS column.
Test T
Markus Amsler a écrit :
I cant try it at the moment, but I tried also the same approach. It
went down from 100s to around 27s compared to 18s with Heap functions.
The other problem here is, not all allocated memory is used, the gaps
in not first nodes never gets filled.
Also IMO memory allo
ements ?
A+
diff --git a/dlls/dbghelp/storage.c b/dlls/dbghelp/storage.c
index e196143..c3ccaf5 100644
--- a/dlls/dbghelp/storage.c
+++ b/dlls/dbghelp/storage.c
@@ -73,30 +73,28 @@ void pool_destroy(struct pool* pool)
void*
ouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
diff --git a/dlls/dbghelp/storage.c b/dlls/dbghelp/storage.c
index e196143..c3ccaf5 100644
--- a/dlls/dbghelp/storage.c
+++ b/dlls/dbghelp/storage.c
@@ -
On 30.04.2007 08:56, Eric Pouech wrote:
> Markus Amsler a écrit :
>> This reduces WoW debug symbol load time from about 100s to 18!
> this also removes two key design features:
> - memory is free:d (as Dimitry already pointed out)
> - a memory pool is associated to every module, so that all allocat
Markus Amsler a écrit :
This reduces WoW debug symbol load time from about 100s to 18!
this also removes two key design features:
- memory is free:d (as Dimitry already pointed out)
- a memory pool is associated to every module, so that all allocations
for a specific module are free:d when the
Dmitry Timoshkov wrote:
The old code at least bothered to actually free some memory.
Good point. I wasn't aware that some memory is only temporarily used.
I'm going to rework it.
Markus
"Markus Amsler" <[EMAIL PROTECTED]> wrote:
void pool_destroy(struct pool* pool)
{
-struct pool_arena* arena;
-struct pool_arena* next;
-
-#ifdef USE_STATS
-unsignedalloc, used, num;
-
-for (alloc = used = num = 0, arena = pool->first; arena; arena = arena->next)
-{
r to apply patches: 1/ dbghelp-elf-map, 2/ dbghelp-elf-alternate,
3/ dbghelp-elf-link-alternate)
A+
[DbgHelp]: allowed to add an alternate file_map for an ELF file (where to
From: Eric Pouech <[EMAIL PROTECTED]>
look for its debug information)
---
dlls/dbghelp/elf
Robert Shearman a écrit :
Eric Pouech wrote:
Robert Shearman a écrit :
Keep the debuglink elf_file_map mapped until after
elf_new_public_symbols is called, otherwise we could use unmapped
memory.
this is still not the full valid solution... what should be done is:
when we search for a giv
Eric Pouech wrote:
Robert Shearman a écrit :
Keep the debuglink elf_file_map mapped until after
elf_new_public_symbols is called, otherwise we could use unmapped
memory.
this is still not the full valid solution... what should be done is:
when we search for a given section, we should look
Robert Shearman a écrit :
Keep the debuglink elf_file_map mapped until after
elf_new_public_symbols is called, otherwise we could use unmapped memory.
this is still not the full valid solution... what should be done is:
when we search for a given section, we should look first in the original
to
> > the hashtable of the parent file.
> > But at the time elf_new_public_symbols is run, the sections of the .debug
> > file are already unmapped.
> > In addition to that the symbols in .debug would be added 2 times (.so and
> > .debug file)
> >
> > Chan
, the sections of the .debug file
are already unmapped.
In addition to that the symbols in .debug would be added 2 times (.so and
.debug file)
Changelog:
dbghelp: fix debuglink crash, accessing memory after munmap
I don't think it's the right fix
IMO, we shouldn't call elf_new
You should make the A function call the W one, not the other way
around.
in theory yes
in practice, it would require rewriting all module storage, lookup...
with unicode strings which is on my todo list, but with a very low
priority. BTW, all the module handling code in dbghelp is already
Eric Pouech <[EMAIL PROTECTED]> writes:
> +BOOL WINAPI EnumerateLoadedModulesW64(HANDLE hProcess,
> + PENUMLOADED_MODULES_CALLBACKW64 E=
> numLoadedModulesCallback,
> + PVOID UserContext)
> +{
> +struct enum_load_mod6
Frank Richter a écrit :
The .gnu_debuglink section contains only a bare filename, however, the
debug file can be in a number of locations. These are stated in the
GDB manual and are now searched when a .gnu_debuglink is encountered.
Frank,
a couple of remarks:
- there are memory leaks in the c
Thomas Fitzsimmons wrote:
This patch fixes #6830.
Tom
2006-12-05 Thomas Fitzsimmons <[EMAIL PROTECTED]>
* dlls/dbghelp/elf_module.c (is_dt_flag_valid): Recognize
DT_GNU_HASH.
diff --git a/dlls/d
On 10/28/06, Michael [Plouj] Ploujnikov <[EMAIL PROTECTED]> wrote:
On 10/28/06, Andrew Talbot <[EMAIL PROTECTED]> wrote:
> Changelog:
> dbghelp: Cast-qual warnings fix.
>
> diff -urN a/dlls/dbghelp/path.c b/dlls/dbghelp/path.c
> --- a/dlls/dbghelp/path.c 20
On 10/28/06, Andrew Talbot <[EMAIL PROTECTED]> wrote:
Changelog:
dbghelp: Cast-qual warnings fix.
diff -urN a/dlls/dbghelp/path.c b/dlls/dbghelp/path.c
--- a/dlls/dbghelp/path.c 2006-07-13 16:13:33.0 +0100
+++ b/dlls/dbghelp/path.c 2006-10-28 16:06:46.0
Roderick Colenbrander wrote:
I have attached a tarball containing two logs one in case it works (log.works)
and one in which it fails (log.fails). When it worked wine was installed
in /usr/local and in the other case in /emul/ia32-linux/usr.
In the working case I executed 'WINEDEBUG=+db
I have attached a tarball containing two logs one in case it works (log.works)
and one in which it fails (log.fails). When it worked wine was installed
in /usr/local and in the other case in /emul/ia32-linux/usr.
In the working case I executed 'WINEDEBUG=+dbghelp winedbg notepad' and
Eric Pouech wrote:
Dbghelp looks for the ELF module in the PATH and LD_LIBRARY_PATH
environment
variables, while the internal loader relies on WINEDLLPATH and the
default DLL dir (or the build one). You could work around this by
setting one of those variables.
Dbghelp needs to be updated to
Dbghelp looks for the ELF module in the PATH and LD_LIBRARY_PATH environment
variables, while the internal loader relies on WINEDLLPATH and the default DLL dir (or the build one). You could work around this by setting one of those variables.
Dbghelp needs to be updated to follow the loader&#
if I install wine into a standard
/usr/local prefix, winedbg works ok aswell. It shows the correct information
and the SymLoadModule lines don't fail either.Most likely there's some path
issue in dbghelp.
I have tried to look at the code but it is a big maze to me. Perhaps you ha
Jan Zerebecki wrote:
I tried to hack on http://bugs.winehq.org/show_bug.cgi?id=4848 and
dbghelp failed on me.
Log about the failure:
http://bugs.winehq.org/attachment.cgi?id=3151&action=view
Jan
Actually, it crashes when loading some stabs information, and closing a
block on a
I tried to hack on http://bugs.winehq.org/show_bug.cgi?id=4848 and
dbghelp failed on me.
Log about the failure:
http://bugs.winehq.org/attachment.cgi?id=3151&action=view
Jan
On Friday 16 June 2006 13:06, Eric Pouech wrote:
> 2006/6/16, Raphael <[EMAIL PROTECTED]>:
> > Hi,
> >
> > Changelog:
> > - map lines section
> > - better robustness
> > - support of unamed syms
> > - better traces
> > - ref hash table to stabilize model
> >
> > TODO:
> > - find a clean
2006/6/16, Raphael <[EMAIL PROTECTED]>:
Hi,Changelog: - map lines section - better robustness - support of unamed syms - better traces
- ref hash table to stabilize modelTODO: - find a clean way to handle forward declarations (some assertions canhappen) - debug lines parsing
I did (in pa
Frank Richter wrote:
On 26.05.2006 21:17, Eric Pouech wrote:
+/**
+ *SymGetSymFromAddr (DBGHELP.@)
+ *
+ */
+BOOL WINAPI SymGetSymFromAddr64(HANDLE hProcess, DWORD64 Address,
+PDWORD64
On 26.05.2006 21:17, Eric Pouech wrote:
>> +/**
>> + *SymGetSymFromAddr (DBGHELP.@)
>> + *
>> + */
>> +BOOL WINAPI SymGetSymFromAddr64(HANDLE hProcess, DWORD64 Address,
>> +
1 - 100 of 141 matches
Mail list logo
