Pelles C debug info, DBGHELP and static storage class

[iZzz32]

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;
}

test.c
polink.exe /debug dbghelp.lib test.obj
Writing debug information
Compacting CodeView information
print_symbol+0

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.

[frankie]

Look here
http://www.debuginfo.com/examples/dbghelpexamples.html

[iZzz32]

frankie, thank you, but there's nothing special in those examples. For example, running SymFromAddr.cpp:

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

Loading symbols for: test.exe ...
Load address: 400000
Looking for symbol at address 401000 ...
Error: SymFromAddr() failed. Error code: 487

[iZzz32]

So I just made a parser for COFF debugging info which calls SymAddSymbol for every IMAGE_SYM_CLASS_STATIC symbol it finds.

[frankie]

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.

[iZzz32]

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.

[CommonTater]

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 ....  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]

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.

[frankie]

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.

[Pelle]

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...

[frankie]

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).

[Robert]

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

[frankie]

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.