NO

Author Topic: Pelles C debug info, DBGHELP and static storage class  (Read 10493 times)

iZzz32

  • Guest
Pelles C debug info, DBGHELP and static storage class
« on: July 24, 2012, 12:17:49 AM »
Is there any solution on how to make DBGHELP.DLL find names of static functions in executables produced by Pelles C? SymFromAddr and SymEnumerateSymbols64 return everything but symbols for static functions and variables. However these names certainly exist in debug information as Pelles C debugger shows these names without any problems. Should I consider writing my own COFF/CodeView parser or is there an easy way?

Code: [Select]
#include <windows.h>
#include <dbghelp.h>
#include <stdio.h>

#ifdef STATIC
static
#endif
void print_symbol(void * addr)
{
  DWORD64           displacement;
  SYMBOL_INFO *     symbol;
  char              buffer[sizeof(SYMBOL_INFO) + MAX_SYM_NAME * sizeof(TCHAR)];

  symbol = (void *) buffer;
  symbol->SizeOfStruct = sizeof(SYMBOL_INFO);
  symbol->MaxNameLen = MAX_SYM_NAME;
 
  if (!SymFromAddr(GetCurrentProcess(), (DWORD64) addr, &displacement, symbol))
    printf("<UNKNOWN>\n");
  else
    printf("%s+%#x\n", symbol->Name, (DWORD) displacement);
   
  return;
}

int main(void)
{
  SymInitialize(GetCurrentProcess(), NULL, TRUE);
  SymSetOptions(SYMOPT_AUTO_PUBLICS);
 
  print_symbol(print_symbol);

  SymCleanup(GetCurrentProcess());
  return 0;
}

Quote from: cc -Zi -Ze test.c dbghelp.lib && test
test.c
polink.exe /debug dbghelp.lib test.obj
Writing debug information
Compacting CodeView information
print_symbol+0

Quote from: cc -Zi -Ze -DSTATIC test.c dbghelp.lib && test
test.c
polink.exe /debug dbghelp.lib test.obj
Writing debug information
Compacting CodeView information
<UNKNOWN>

Btw, there's still an old bug in Pelles C 7: Pelles C does not display a name of the very first function in disassembly view.

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2113
"It is better to be hated for what you are than to be loved for what you are not." - Andre Gide

iZzz32

  • Guest
Re: Pelles C debug info, DBGHELP and static storage class
« Reply #2 on: July 24, 2012, 11:11:13 AM »
frankie, thank you, but there's nothing special in those examples. For example, running SymFromAddr.cpp:

Quote from: symfromaddr test.exe 401000 (test.exe is an example above)
Loading symbols for: test.exe ...
Load address: 400000
Looking for symbol at address 401000 ...
Symbol found:
Symbol: Unknown  Address: 401000  Size: 131  Name: print_symbol

Quote from: symfromaddr test.exe 401000 (test.exe is an example above built with -DSTATIC)
Loading symbols for: test.exe ...
Load address: 400000
Looking for symbol at address 401000 ...
Error: SymFromAddr() failed. Error code: 487

iZzz32

  • Guest
Re: Pelles C debug info, DBGHELP and static storage class
« Reply #3 on: July 25, 2012, 02:27:00 PM »
So I just made a parser for COFF debugging info which calls SymAddSymbol for every IMAGE_SYM_CLASS_STATIC symbol it finds.

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2113
Re: Pelles C debug info, DBGHELP and static storage class
« Reply #4 on: July 25, 2012, 04:05:23 PM »
I think that to do by itself it's the best solution.
Just for info: the problem is the same with modules compiled with M$VC?
Maybe Pelle's symbols are a little out of standard.
"It is better to be hated for what you are than to be loved for what you are not." - Andre Gide

iZzz32

  • Guest
Re: Pelles C debug info, DBGHELP and static storage class
« Reply #5 on: July 25, 2012, 08:57:34 PM »
As I can understand the problem is that DBGHELP does not (?) parse sstAlignSym subsection in CodeView debug information. Nothing to do with POCC (well, I'd be glad to see PDB support in POLINK  :) ).

Yes, symbols are resolved perfectly when I compile with MSVC (it produces PDB and DBGHELP likes PDB). Even compiling with POCC and linking with MS LINK (8.0 from VS2003, for example) works as it results in linker producing PDB too.

Upd: as for "compiling with POCC, linking with LINK" solution: for something bigger than test.c posted above I just get "LINK : fatal error LNK1102: out of memory" everytime.
« Last Edit: July 25, 2012, 09:55:45 PM by iZzz32 »

CommonTater

  • Guest
Re: Pelles C debug info, DBGHELP and static storage class
« Reply #6 on: July 25, 2012, 10:23:56 PM »
Upd: as for "compiling with POCC, linking with LINK" solution: for something bigger than test.c posted above I just get "LINK : fatal error LNK1102: out of memory" everytime.

This is likely a difference in standards... Pelle has them, MS does not :D ....  That is to say you can't really expect a non-standard linker based mostly on C-89 to work with C-99 and C-11 object code.

iZzz32

  • Guest
Re: Pelles C debug info, DBGHELP and static storage class
« Reply #7 on: July 25, 2012, 10:47:02 PM »
Quote
That is to say you can't really expect a non-standard linker based mostly on C-89 to work with C-99 and C-11 object code.
Object file format is still [MS]COFF. It does not change. And MS LINK works with .obj files from POCC like any other linker does. The problem is in debugging information again. MS LINK starts generating PDB and… something bad happens.

pocc -c -Ze -Zi single.c && link /INCREMENTAL:NO /DEBUG single.obj – everything's ok,  LINK makes exe and pdb;

pocc -c -Ze -Zi for multiple files && link /INCREMENTAL:NO /DEBUG files – LNK1102 error;

pocc -c -Ze for multiple files && link /INCREMENTAL:NO /DEBUG files – no error (note that there's no -Zi option this time and no debugging info in .obj), I get exe and pdb, but pdb contains only public symbols from COFF symbol table.


Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2113
Re: Pelles C debug info, DBGHELP and static storage class
« Reply #8 on: July 26, 2012, 10:08:44 AM »
As far as I know Pelle still use the CodeView format with some extensions, not sure about COFF (if it is fully M$ COFF).
Maybe is is not fully compliant. On the other way they are fully working with Pelle debugger, so there is no strict requirement to be compatible with other debuggers (conseguentially to be compatible with DBGHELP).

EDIT:
It uses only CodeView. If you link with only COFF selected no symbol, unless globals, nor source is showed.
« Last Edit: July 26, 2012, 10:15:04 AM by frankie »
"It is better to be hated for what you are than to be loved for what you are not." - Andre Gide

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 2266
    • http://www.smorgasbordet.com
Re: Pelles C debug info, DBGHELP and static storage class
« Reply #9 on: September 01, 2012, 08:35:42 PM »
I think this have been discussed in the past. The CodeView format was documented for a few years by Microsoft, but is now considered propriarity. I can't support an undocumented but evolving debugging format (and for Windows there is no better format to change to). For X64 I even had to invent my own signature, effectively creating a "Pelles C CodeView format"...

I think MS stated at some point that the COFF debugging format was dropped.

This must at least be part of the problem...
/Pelle

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2113
Re: Pelles C debug info, DBGHELP and static storage class
« Reply #10 on: September 03, 2012, 04:51:13 PM »
If I'm not wrong the last documented codeview format is CodeView 4, but actually it should be 6 or 7.
I think is hard to decide what to do, make a proprietary format or maybe evaluate a free documented opens source format (definetly not MS).
"It is better to be hated for what you are than to be loved for what you are not." - Andre Gide

Offline Robert

  • Member
  • *
  • Posts: 247
Re: Pelles C debug info, DBGHELP and static storage class
« Reply #11 on: September 04, 2012, 12:53:55 AM »
Jeremy Gordon, the GoAsm man, has a page titled The RSDS pdb format at

http://www.godevtool.com/Other/pdb.htm

which in part says

This file describes the format of the pdb (Program Database) files of the "RSDS" or "DS" type which are emitted by Microsoft's link.exe from version 7 and above.

....

What are PDB files?

The latest Microsoft linkers create a Program Database (pdb) file when linking if the /DEBUG option, or /DEBUG:FULL option is chosen. The pdb file contains information about the creation of the executable, and also contains the symbol information in the latest CodeView format. The executable contains a path and filename for the pdb file on the local machine, together with an identification code, so that the correct pdb file can be located. Neither the format of the pdb file itself nor the latest CodeView format are documented. To my knowledge, the format has changed twice already and it is likely to change again. Microsoft provide APIs to analyse and report the contents of the pdb files in its Debug Information Access (DIA) SDK, but unfortunately this is available only if you subscribe to the Enterprise edition of MSDN or purchase Visual Studio .NET.

Robert Wishlaw

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2113
Re: Pelles C debug info, DBGHELP and static storage class
« Reply #12 on: September 04, 2012, 10:05:59 AM »
Robert the PDB files are more or less the DEBUG section exported in a separate file. In the executable remains only a link to the file containing symbols (typically file name with full path).
The problem with CodeView is that MS change it at any time and don't document the format. The documentation you found around comes from a kind of reverse engineering of the format.
So what is MS intent to don't document the format? Maybe we are not allowed to use it in non MS software, and moreover is not acceptable to make a lot of work each time they update the format.
"It is better to be hated for what you are than to be loved for what you are not." - Andre Gide