5

I'd like to add the map file as resource, then extract the file every time that execute the system, to ensure that the map file is always right, and make the life of support easier. In Delphi 7 I can compile the project, with the map file as resource, but the map is wrong, because when an exception is raised the call stack is wrong. In Delphi Seattle, I can't even compile, because it tries to add the resource before generate the map. I know that I can add the file in a post-compile thask, but is there any way to do it in compiling/building time? Sorry if I'm not very specific, that's my first question here. Thanks.

UPDATE

After I read some answers, I did some research. I was already using JEDI exception unit in my project, but I did not know the JEDI Debug expert. It does exactly what I want and more. JEDI Debug expert convert a .map file to .jdbg file, wich is an encrypted file of map (map is just a text file). Also, the jdbg file is about 12% smaller then the map. It also has the options to insert the jdbg into binary (exe). To do that, I enabled the options:

  • Project -> JCL Debug expert -> Generate .jdbg files -> Enabled for this project

  • Project -> JCL Debug expert -> Insert jdbg data into binary -> Enabled for this project

  • Project -> JCL Debug expert -> Delete map files after conversion -> Enabled for this project (if you want to delete the file, of course)

To use this tool outside the IDE, with Jenkins for example, I had to build the project available in JEDI\jcl\examples\windows\debug\tools\MakeJclDbg.dpr. After build, it will generate the exe file in the bin directory of jcl. How to use:

MakeJclDbg -J -E -M map_filename

J - Create .JDBG files

E - Insert debug data into executable files

M - Delete MAP file after conversion

Executable files must be in the same directory as the MAP files. This will create the jdbg file (based in the map file), insert into the exe and delete the map. With this (and with the exception unit of JEDI), when an exception is raised, It's available to me the stack trace, the versions of all dll's used by the system, operation system info, and more, and also send all this to an email.

I realised that Embarcadero also have jdbg files of theirs bpl, so I think they use JCL tool as well.

Rodrigo Caetano
  • 379
  • 1
  • 13
  • 2
    @Jerry: What *code*? The question asks about adding a **resource** to the executable. There's no code involved. It's a map file generated by the linker when the executable is built. – Ken White Nov 04 '16 at 16:33
  • 2
    @Jerry: No. You can also add it from the command line or a post-build event using brcc or the MS rcc. But even if you're asking the IDE to do it, it's still not code; it's a compiler directive, which is a simple `{$R filename.ext}` – Ken White Nov 04 '16 at 16:38
  • 3
    @Rodrigo: JEDI has the ability to embed the map file in the executable for you, and a debug unit you can use directly in your app to use it without extracting it to disk. Other debugging tools (such as MadExcept and Eureka) also have the same functionality. It's much easier to use one of them rather than attempting to roll your own. – Ken White Nov 04 '16 at 16:40
  • 2
    @Jerry: The *placement* of a compiler directive to add a resource is irrelevant. Resources are added by the link process, which happens after the compiler has completed its work. (Resources are actually added after the linker has finished, because they're added to the final executable; that's why you can manually add them to an existing exe yourself with brcc.) – Ken White Nov 04 '16 at 16:43
  • @Ken Yes, but OP doesn't say anything about *how* they're attempting to add this resource. The question doesn't hint whether they're using post-build scripts or a compiler directive or manual command line. This is the point I was trying to get to. We have no idea how this resource is being added. For all we know, the wrong file could be getting compiled. – Jerry Dodge Nov 04 '16 at 17:01
  • @Ken And since OP is talking about "tries to add the resource before generate the map" that kinda rules out manually using the command-line. This type of problem still is best asked with an MCVE. – Jerry Dodge Nov 04 '16 at 17:07
  • @JerryDodge: "whether they're using post-build scripts ..." The OP says "I know that I can add the file in a post-compile t[h]ask" which implies he isn't atm. – MartynA Nov 04 '16 at 17:15
  • 1
    @MartynA Exactly, that's my point. You must not have seen my original comment(s) which I since deleted after Ken joined, regarding the compiler directive `{$R ... }`. Regardless - all I'm saying is that we don't know what OP *is* doing, and should put in more effort to describe the problem and what has been tried - not what hasn't been tried yet. – Jerry Dodge Nov 04 '16 at 17:17
  • I'm also sorry you aren't very specific. – David Heffernan Nov 04 '16 at 21:13
  • Thanks everyone for your answers. @KenWhite, I am already using JEDI tool in the project. I think that I'll continue to use the map as a separate file, since the use of debug information increases too much the size of the .exe. Perheps I test the MadExcept, since everyone talks about it. – Rodrigo Caetano Nov 07 '16 at 11:56

2 Answers2

2

No, the map file is generated after the program output is linked. It is impossible to incorporate a, not-yet generated, map file as a resource into the project.

Sertac Akyuz
  • 54,131
  • 4
  • 102
  • 169
1

You're missing the point.

The MAP files are generated as a separate file to avoid increasing the size of your executable. Trying to embed that file back into the executable as a resource simply defeats the purpose.

You haven't mentioned what debug framework you're using. But there are other ways to provide debug information, and I suggest you refer to the documentation of the debug framework you using for the specifics. I'll just offer some general concepts applicable to most of the frameworks I've tried.

  • If you're happy with increased EXE size and want debug information included within your executable: Don't use the map file option. Simply enable the linking option to include debug information. (And ensure your debug framework will use it.)
  • Most debug frameworks recommend compiling with stack frames turned on. This is very important because it makes it easier for the debug framework to deduce the call stack.
  • Some debugging frameworks have a feature that allows guessing missing call stack information. If enabled, you will need to manually ignore any stack entries that don't actually make sense.
  • Of course, don't forget that any units compiled without debug information won't have debug information to include in the final executable.
Disillusioned
  • 14,635
  • 3
  • 43
  • 77
  • I'm using JEDI tool as debug framework. I didn't know about the debug information. I tested here, but the size of EXE increses too much, much more than simple add the map file size into EXE. I think I'll continue to use the map file. – Rodrigo Caetano Nov 07 '16 at 12:02