Alistair Leslie-Hughes writes:
> @@ -1717,6 +1717,17 @@ BOOL WINAPI SymGetLineNext64(HANDLE hProcess,
> PIMAGEHLP_LINE64 Line)
> }
>
> /**
> + * SymGetLineNextW64 (DBGHELP.@)
> + *
> + */
> +BOOL WINAPI SymGetLineNextW
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
unfortunat
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
> filenames, we need a unicode
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 the other way around.
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
image_priva
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(+), 40 deletions(-)
>>
>> diff --git a/dlls/db
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 4
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
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,10 +896,10 @@ static int stab
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
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.
On Jan 22, 2008 4:00 PM, Eric Pouech <[EMAIL PROTECTED]> wrote:
> Jason Green a écrit :
> > Re-responses from Eric van Beurden:
> >
> >
> >> hmm I still don't get how, in a generic way symbols could overlap
> >> the only think I could come up with if when static functions get
> >> automatically inl
Re-responses from Eric van Beurden:
> hmm I still don't get how, in a generic way symbols could overlap
> the only think I could come up with if when static functions get
> automatically inlined by the compiler, but that's rather a different
> story (as I'd suspect the inlined function to be a sin
Jason Green a écrit :
> 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
> imp
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,
Jason Green a écrit :
>
>
> From 1127317807ec264541e2e03e6a633cefee8f697b Mon Sep 17 00:00:00 2001
> From: Jason Green <[EMAIL PROTECTED](none)>
> Date: Thu, 17 Jan 2008 17:43:41 -0500
> Subject: [PATCH] Clamp minidump memory
Jason Green a écrit :
>
>
> From ad95ee9cad0df8b4e8ca35d2d5a280d755c7bf7f Mon Sep 17 00:00:00 2001
> From: Jason Green <[EMAIL PROTECTED](none)>
> Date: Thu, 17 Jan 2008 17:21:00 -0500
> Subject: [PATCH] Fix file searching to
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);
> +
> +
"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 a
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 time was han
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 usage
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 with ps -AF
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 the RSS co
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.
Test
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
Eric Pouech wrote:
Markus Amsler a écrit :
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
does this patch gives you lots of improvements ?
A+
Markus Amsler a écrit :
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
does this patch gives you lots of improvements ?
A+
--
Eric Pouech
"The prob
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)
-{
Eric Pouech a écrit :
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:
w
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
On Sunday 21 January 2007 16:25, Eric Pouech wrote:
> Peter Oberndorfer a écrit :
> > Winedbg would crash on my system when trying to set a breakpoint (loading
> > the debug info from a .debug file)
> > The problem is that hash_table_elt adds the symbols of the .debug file to
> > the hashtable of
Peter Oberndorfer a écrit :
Winedbg would crash on my system when trying to set a breakpoint (loading the
debug info from a .debug file)
The problem is that hash_table_elt adds the symbols of the .debug file to the
hashtable of the parent file.
But at the time elf_new_public_symbols is run, the
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
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 2006-07-13 16:13:33.0 +0
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 +0100
@@ -
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 Dis
On 26.05.2006 21:17, Eric Pouech wrote:
>> +/**
>> + *SymGetSymFromAddr (DBGHELP.@)
>> + *
>> + */
>> +BOOL WINAPI SymGetSymFromAddr64(HANDLE hProcess, DWORD64 Address,
>> +PDWORD64 Displacement,
Thomas Weidenmueller wrote:
The attached patch implements SymGetSymFromAddr64, called by steam.
a couple of coments:
@@ -996,7 +996,8 @@
sym = pair.effective->addr_sorttab[idx];
symt_fill_sym_info(&pair, &sym->symt, Symbol);
-*Displacement = Address - Symbol->Address;
+if
Eric Pouech <[EMAIL PROTECTED]> writes:
> ChangeLog:
> - implemented StackWalk64 (reusing StackWalk)
You should really reuse it, not just duplicate such a big chunk of
code.
--
Alexandre Julliard
[EMAIL PROTECTED]
Eric Pouech wrote:
/* dbghelp.c */
extern struct process* process_find_by_handle(HANDLE hProcess);
+extern BOOL validate_addr64(DWORD64 addr);
extern HANDLE hMsvcrt;
extern BOOL validate_addr64(DWORD64 addr);
validate_addr64 is duplicated.
--
Rob Shearman
Raphael wrote:
but it's of no use with the patch you sent, so why clobber the patch
with this ?
no because i think its better to avoid assert in this case on dbghelp code :)
But if you prefer i can restore original code
IMO the correct fix would in field insertion to return one of three valu
> but it's of no use with the patch you sent, so why clobber the patch
> with this ?
no because i think its better to avoid assert in this case on dbghelp code :)
But if you prefer i can restore original code
> A+
Regards,
Raphael
pgpUAB1PaRkR3.pgp
Description: PGP signature
Raphael wrote:
On Monday 10 October 2005 21:27, Eric Pouech wrote:
BOOL symt_add_udt_element(struct module* module, struct symt_udt*
assert(m->symt.tag == SymTagData);
if (m->hash_elt.name[0] == name[0] && strcmp(m->hash_elt.name,
name) == 0) -return TRUE;
+
On Monday 10 October 2005 21:27, Eric Pouech wrote:
> > BOOL symt_add_udt_element(struct module* module, struct symt_udt*
> assert(m->symt.tag == SymTagData);
> > if (m->hash_elt.name[0] == name[0] && strcmp(m->hash_elt.name,
> > name) == 0) -return TRUE;
> > +
Raphael wrote:
Hi,
Changelog:
- begin of dwarf debug lines parsing
- better robustness
- support of unamed syms
- better traces
TODO:
- find a clean way to handle forward declarations
- debug lines parsing
Index: type.c
===
On Tuesday 24 May 2005 12:15, Alexandre Julliard wrote:
> Raphael <[EMAIL PROTECTED]> writes:
> > Hi,
> >
> > This times symt model construction seems good :)
> >
> > But for debug lines, i don't really understand the sm/regs concept :(
> >
> > Changelog:
> > - implement dwarf2_find_symt_by_ref an
> > > > Changelog:> > - implement dwarf2_find_symt_by_ref and dwarf2_add_symt_ref using hashtables> > - some debug lines defines> > - handle forwards references (ie dwarf2_find_symt_by_ref returns NULL) using > > ref hashtable> > - better traces > > It doesn't compile, you probably forgot part of
Raphael <[EMAIL PROTECTED]> writes:
> Hi,
>
> This times symt model construction seems good :)
>
> But for debug lines, i don't really understand the sm/regs concept :(
>
> Changelog:
> - implement dwarf2_find_symt_by_ref and dwarf2_add_symt_ref using hashtables
> - some debug lines defines
>
Eric Pouech a écrit :
minidumps now contain more accurate information about modules,
especially information that will allow when reloading a minidump in a
debugger to check whether we're using the right modules (ELF & PE)
implemented also check for this information in SymFindFileInPath
A+
Please
Robert Reif a écrit :
I can't get a stack trace with symbol information from an
exe file and tracked the problem down to this.
dbghelp tries to load the symbols for the executable file
by looking up the file name without the .exe extension and
fails because the file is not found. This patch adds t
Dimitrie O. Paun a écrit :
On Thu, Nov 11, 2004 at 09:25:46PM +0100, Eric Pouech wrote:
This (huge) patch does:
- apart from restructuring the code (COFF handling goes to new coff.c
file, Codeview and PDB defines and types to new mscvpdb.h file)
^^
Dimitrie O. Paun wrote:
On Thu, Nov 11, 2004 at 09:25:46PM +0100, Eric Pouech wrote:
This (huge) patch does:
- apart from restructuring the code (COFF handling goes to new coff.c
file, Codeview and PDB defines and types to new mscvpdb.h file)
On Thu, Nov 11, 2004 at 09:25:46PM +0100, Eric Pouech wrote:
> This (huge) patch does:
> - apart from restructuring the code (COFF handling goes to new coff.c
> file, Codeview and PDB defines and types to new mscvpdb.h file)
^
Shouldn't th
Le ven 08/10/2004 à 13:48, Eric Pouech a écrit :
> Vincent Béron a écrit :
> > Hi,
> >
> > I noticed that dbghelp's functions are only implemented as A variant,
> > while MSDN says they're available as either Unicode or Ascii variant.
> > Should we rename the current ones A and create stub W befor
Vincent Béron a écrit :
Hi,
I noticed that dbghelp's functions are only implemented as A variant,
while MSDN says they're available as either Unicode or Ascii variant.
Should we rename the current ones A and create stub W before properly
implementing in W and make the A call the W?
you shouldn't re
On Thu, 7 Oct 2004, Vincent Béron wrote:
[...]
Also, I noticed quite a lot of prototypes in dbghelp.dll from MSDN with
PTSTR or PCTSTR types for strings instead of LPTSTR. Should the
prototype in dbghelp.h and the actual implementation use PTSTR or
LPTSTR?
TSTR is the same as TCHAR: it's either ANS
Is the attached patch correct?
yes
Eric Pouech wrote:
Robert Shearman a écrit :
How does the attached patch look?
better, but you should to nuke srcpath (and no longer currpath) in
N_SO case, when *ptr is '\0' (it's defensive code, so it shouldn't
harm on normally formed stabs file). As a side effect, you don't need
also to memse
Robert Shearman a écrit :
How does the attached patch look?
better, but you should to nuke srcpath (and no longer currpath) in N_SO
case, when *ptr is '\0' (it's defensive code, so it shouldn't harm on
normally formed stabs file). As a side effect, you don't need also to
memset currpath to 0 at
Eric Pouech wrote:
which means that:
- we create a new compilation unit (for example) on 2205 => this gives
the source directory
- we start the main compilation unit on 2206 =>
/home/dm/wine/dlls/dbghelp/elf_module.c
- in this CU, we start a new include file (on ), =>
/home/dm/wine/dlls/dbgh
which means that:
- we create a new compilation unit (for example) on 2205 => this gives
the source directory
- we start the main compilation unit on 2206 =>
/home/dm/wine/dlls/dbghelp/elf_module.c
- in this CU, we start a new include file (on ), =>
/home/dm/wine/dlls/dbghelp/../../include/w
Eric Pouech wrote:
Robert Shearman a écrit :
Hi,
On startup, the debugger usually prompted me to type the path where
"/winternl.h" can be found. This was due to the path being stored
internally as "../../include/winternl.h", i.e. relative to the source
directory. This patch adds the ability to s
Robert Shearman a écrit :
Hi,
On startup, the debugger usually prompted me to type the path where
"/winternl.h" can be found. This was due to the path being stored
internally as "../../include/winternl.h", i.e. relative to the source
directory. This patch adds the ability to store the source dir
Jon Griffiths a écrit :
Hi,
Some overly long stabs cause crashes when debug tracing is enabled.
Cheers,
Jon
+dlls/dbghelp/stabs.c
Prevent the debug buffer from overflowing on long stabs
You shouldn't use debugstr_an with a fixed value, since all strings are
'\0' terminated.
Either fix dlls/n
> UnDecorateName is still a stub, while our winedump has some a good> framework for UnDecorateName, also translating into a GCC way and not in a> VC++ way. How should these things go together?
See the comment in dbghelp.c !! My first thouhgt would be to make a .a lib out of winedump code, and use
> "Eric" == Eric Pouech <[EMAIL PROTECTED]> writes:
Eric> Eric Pouech a écrit :
>> This is a first (and incomplete) shot at implementing the dbghelp
>> DLL.
Eric> forgot to say that: - this patch must be applied before the ones
Eric> on imagehlp & taskmgr - code is highly d
99 matches
Mail list logo
