We help IT Professionals succeed at work.

Core files: debugging and general confusion!

mrwad99
mrwad99 asked
on
Ah hello

I am completely new to Solaris programming, having come from a heavy windows background, and am trying to understand how to debug core files and how core files work in general.

I am using SunStudio 12 on Solaris 8 (Solaris 8 2/04 s28s_hw4wos_05a SPARC), and have the following very simple source file which generates my crash.

#include <stdlib.h>

int main(int argc, char** argv) {
    int* p = 0;
    *p = 42;
    return (EXIT_SUCCESS);
}

Open in new window


This is contained in the folder \SunStudioProjects\CrashTest_1, along with the generated Makefile and output folders.  Now, when I build the program in the Debug configuration and run it through the SunStudio IDE, I get the core file generated, and placed in my project directory.  All good so far.  I then tell SunStudio to debug this core file via "Run->Debug Core file...", selecting the core file, leaving the Executable option as <from core> and Project as <no project>.  I then get my source file opened, with the faulting line highlighted.  Great.  Now the questions...

1) When I build and run the release configuration, I get no opening of the source file: instead, DBX tells me

program terminated by signal SEGV (no mapping at the fault address)
0x00010dcc: main+0x0004:        st       %o5, [0]

Open in new window


Why is this, and how can I fix it please?

2) I rename my "build" folder within \SunStudioProjects\CrashTest_1, then debug the core file again.  Surprisingly, I still get my source file opened, correctly identifying the faulting line.  I thought that the object files (contained in this "build" directory) were essential for debugging...where is the source file path being stored?

3) When I build a binary in release mode, and it goes out "into the wild, so to speak" (i.e. is released to the public) what files do I need to keep in order to be able to debug any core dumps that may be generated?

I have put the points @ 300 currently (100/question) but this will go up if I ask follow up questions.

Many thanks in advance.
Comment
Watch Question

SILVER EXPERT
Distinguished Expert 2019

Commented:
The error sigseg means you have an error in the code that passes the compiler validation but does not work when executed.

i.e. at times type mismatch in assignments can lead to sigseg error.

In your case the issue is with
int* p=0; which seems you are trying to assign a value to a pointer variable.
*p=42; before you allocated space to the pointer
replacing the above with
    int* p= (int *) malloc(sizeof(int));
    *p = 42;

will work.

Author

Commented:
arnold

Thanks for commenting.  I do think however that you have misunderstood what I am asking...

I am aware of why the code crashes; I have intentionally made it do so.  My questions (1, 2 and 3 above) lie purely in using SunStudio/DBX to be able to debug a core file from a release mode binary...

Thanks.
Brian UtterbackPrinciple Software Engineer
BRONZE EXPERT

Commented:
I am confused about what you are asking. Are you running the debugger through the IDE or are you running dbx alone? In the release version of the binary, the symbols are stripped out, so dbx does not know what they are or where the source code is. It also is optimized, so the code does not necessarily match the source lines anymore. This makes it even more difficult for dbx to display source lines.

So, to tell dbx where the source files are, you can use the "pathmap" command in dbx. Try "help pathmap" to see how it works. You can use the files command to tell you what files the object expects to find.  But this may not work if the executable was stripped or optimized.

To debug your released programs, you need the executable (preferably unstripped), the core file, and
all the shared library files that the executable uses from the system it was running on when the core was created.

Author

Commented:
blu

Thanks for participating.

The debugger that SunStudio uses is dbx: see the attached screenshot, particularly the "Dbx console" - it is showing the output I see after I tell SunStudio to debug the core file generated from the release mode binary.

I have read about the pathmap command before, but never had any joy from it.  According to the help pages, I need to use it with dbxenv core_lo_pathmap set to 'on'.  I think I would  need to use it if I was debugging the core on a different machine from which it was built, kind of as a way of saying "you are expecting the source to be at X, but I want you to find it at Y": pathmap /X /Y.  So, the 'files' command tells me some interesting stuff, such as

(dbx) (dbx) files
crashtest_1:
  CrashTest_1.cc
libc.so.1:
  ../port/gen/atexit.c
  crt/_ftou.c
  crt/divrem64.c
  crt/mul64.c
  crt/_rtld.c
  fp/_Q_add.c
  fp/_Q_cmp.c

Now, the CrashTest_1.cc file appears to be being looked for in the root (which I assume is parallel to the core file) - in which case, it is there!  So why is it not being found?!  I have no need to use pathmap then - the file is where it is expected to be!  Also, I don't have any of the other files (../port/gen/atexit.c, crt/divrem64.c etc) so how are they meant to be found??

What do you mean by shared library files?  How can I generate an unstripped executable in SunStudio, do you know?

(Sorry, I hardly know anything about Solaris and am a total novice.  Please bear with me.)

Author

Commented:
Brian UtterbackPrinciple Software Engineer
BRONZE EXPERT

Commented:
I don't know why it isn't finding the source file. When I run dbx by itself in either the project directory where the core is or in the dist sub directory where the executable is, it finds the source code.

However, when I take the executable and run it through the strip command, then it does not find the source file and it only shows the assembly as you had above.

You can use the solaris "file" command to tell you whether or not an excutable is stripped. For instance, I can do this:

sr1-ubur-05{blu}595:  ls -l ee-test
-rwxr-xr-x   1 blu      staff       3736 Nov  4 11:21 ee-test*

sr1-ubur-05{blu}596:  file ee-test
ee-test:        ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, stripped

Shared libraries are the files that the executable maps in that are shared between executables. You can use the ldd command to list them:

sr1-ubur-05{blu}598:  ldd ee-test
        libc.so.1 =>     /lib/libc.so.1
        libm.so.2 =>     /lib/libm.so.2

In general, the core file will not contain the actual assembly code for shared libraries, so you need
the libraries for the debugger to be able to show you what was at a particular address.

Author

Commented:
OK, that is very useful to know, thanks.  With the output from ldd, I can see why I might need to use pathmap to "re-educate" dbx on where the libararies actually are.

Regarding stripping, when I run "file" on my binary that SunStudio built for me, it shows

./crashtest_1:  ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped

Which would suggest that it should be debuggable, right?  Now, you say that you can run dbx "by itself", and it finds the source file.  I take it this means "not through SunStudio", like through a normal terminal window, right? When I do this,  I still get the disassembly but no source file opened: what do you mean when you say it "finds the source file"?

Thanks again.
Brian UtterbackPrinciple Software Engineer
BRONZE EXPERT

Commented:
I mean that when I cd into the project directory, there is a core file there and a dist directory and the source file. If I run dbx like this:

dbx dist/.../ee-test core

It loads and displays the source file line where the program crashed.
If I cd into the dist directory to where the executable is and run dbx like this:

dbx ee-test ../../../core

it still prints the source line.

Michael EagerConsultant

Commented:
What is the command line used to compile the program?  

You need to specify -g to generate debug information.  Otherwise DBX will not find the source.

Author

Commented:
blu:

I tried as you suggested and do get the source line displayed when I 'dbx' the debug, but not the release.  See below:

Debug:
 
dbx ./crashtest_1 core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.5' in your .dbxrc
Reading crashtest_1
core file header read successfully
Reading ld.so.1
Reading libCstd.so.1
Reading libCrun.so.1
Reading libm.so.1
Reading libc.so.1
Reading libdl.so.1
Reading libCstd_isa.so.1
Reading libc_psr.so.1
program terminated by signal SEGV (no mapping at the fault address)
Current function is main
   15       *p = 42;

Open in new window


Release:

dbx ./crashtest_1 ./core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.5' in your .dbxrc
Reading crashtest_1
core file header read successfully
Reading ld.so.1
Reading libCstd.so.1
Reading libCrun.so.1
Reading libm.so.1
Reading libc.so.1
Reading libdl.so.1
Reading libCstd_isa.so.1
Reading libc_psr.so.1
program terminated by signal SEGV (no mapping at the fault address)
0x00010dcc: main+0x0004:        st       %o5, [0]

Open in new window


eager:

Thanks for joining in.  SunStudio has generated me a makefile which it runs via dmake on the command line.  I don't understand how it works; put bluntly, the whole reason I use an IDE is so I don't need to and can just concentrate on the code.

I would really appreciate it if someone who has SunStudio can take a look at this and tell me what the problem is.  I have uploaded the project files (only 7KB).  https://www.yousendit.com/download/T2dkSlI2UENtUUUxZXNUQw

TIA
Michael EagerConsultant

Commented:
It has been a long time since I did anything with SunStudio.  It looks like it is building two versions of the program: a debug version and a release (i.e., stripped) version.  I would guess that there is a way to tell it whether to run the release or the debug version of your program, either as a menu selection or as an option.  If you run the release version, you won't see any debug info.
Brian UtterbackPrinciple Software Engineer
BRONZE EXPERT

Commented:
The difference between the debug version is probably one or more of the following:

Using the -O flag instead of the -g
Using a stripped binary instead of unstripped.

Use the file command from before on the executable of the release version to see if it is stripped or not. If it is stripped, it may be possible to make a copy of the executable prior to its being stripped. In that case you can use the unstripped executable in place of the stripped one when you do the debugging. However, if you are using -O instead of -g, replacing the executable will not work. You may have to decide whether it is more important to have optimized code or debuggable code. With SunStudio, the -O and -g flags are mutally exclusive, but gcc does allow you to specifiy both. The optimizations can make the final code generated unmappable to the original source code, but gcc allows dbx to make the attempt. SunStudio does more optimizations, so in the end they decided that it was a losing game to allow both flags.

Author

Commented:
eager, I know how to run the binary using the IDE.  The problem is that I cannot get the same output when I debug the release core file as when I debug the 'debug' core file; that is, the line number and faulting piece of code, as shown by the output from dbx in my comment of 05/11/11 09:28 PM.

The release executable is not stripped (output from 'file' shown in my comment of 04/11/11 04:36 PM).  This corresponds with the 'Linker/General/Strip symbols' option in the IDE not being ticked.

Also, I have read in the release makefile

dist/Release/Sun12-Solaris-Sparc/crashtest_1: ${OBJECTFILES}
	${MKDIR} -p dist/Release/Sun12-Solaris-Sparc
	${LINK.cc} -g -o dist/Release/Sun12-Solaris-Sparc/crashtest_1 ${OBJECTFILES} ${LDLIBSOPTIONS} 

Open in new window


You can clearly see the -g option there.

So why is dbx not showing me the faulting line?!? Argghhhh!  How can this be so difficult - I am not asking the world am I???

I have posted a link to this question in hopefully relevant zones in an attempt to get an answer to this...
Michael EagerConsultant

Commented:
Yes, I looked a the makefile in your project.  As you say, -g is specified and it does not strip the executable.

When dbx displays an instruction rather than a source location, there is really only one cause:  not finding debug info for the program.  This does not mean that it couldn't find the source directory: that results in an error message.  Dbx did not look for the source.  Also, it has nothing to do with libraries or pathmap.  

Please explain again what you are doing when you said you "do get the source line displayed when I 'dbx' the debug, but not the release."  You show running dbx from the command line on an executables in the current directory, but it isn't clear what directory you are in.   Are there two different directories?  If yes, can you run "file" on the executable in these directories?

Author

Commented:
OK.  Hereis a comprehensive description of what I am doing, split into debug and release configurations.

Debug configuration
I select the debug configuration and hit build.  The following output is shown by SunStudio:

Running "/opt/SUNWspro/bin/dmake  -f Makefile CONF=Debug" in /home/bild/SunStudioProjects/CrashTest_1

dmake: defaulting to parallel mode.
See the man page dmake(1) for more information on setting up the .dmakerc file.
powerhouse --> 1 job
/opt/SUNWspro/bin/dmake -f nbproject/Makefile-Debug.mk SUBPROJECTS= .build-conf
powerhouse --> 1 job
mkdir -p build/Debug/Sun12-Solaris-Sparc
CC    -c -g -o build/Debug/Sun12-Solaris-Sparc/CrashTest_1.o CrashTest_1.cc
powerhouse --> Job output
mkdir -p build/Debug/Sun12-Solaris-Sparc
CC    -c -g -o build/Debug/Sun12-Solaris-Sparc/CrashTest_1.o CrashTest_1.cc
(/home/bild/SunStudioProjects/CrashTest_1)CrashTest_1.cc:
:(/home/bild/SunStudioProjects/CrashTest_1)CrashTest_1.cc
powerhouse --> 1 job
mkdir -p dist/Debug/Sun12-Solaris-Sparc
CC    -o dist/Debug/Sun12-Solaris-Sparc/crashtest_1 build/Debug/Sun12-Solaris-Sparc/CrashTest_1.o  
powerhouse --> Job output
mkdir -p dist/Debug/Sun12-Solaris-Sparc
CC    -o dist/Debug/Sun12-Solaris-Sparc/crashtest_1 build/Debug/Sun12-Solaris-Sparc/CrashTest_1.o  
(/home/bild/SunStudioProjects/CrashTest_1)build/Debug/Sun12-Solaris-Sparc/CrashTest_1.o:
:(/home/bild/SunStudioProjects/CrashTest_1)build/Debug/Sun12-Solaris-Sparc/CrashTest_1.o

Build successful. Exit value 0.

Open in new window


I then run the binary through SunStudio.  I get the following output, and a nice window popup which contains the text

"Segmentation fault - core dumped"

Running "/opt/SUNWspro/bin/dmake  -f Makefile CONF=Debug" in /home/bild/SunStudioProjects/CrashTest_1

dmake: defaulting to parallel mode.
See the man page dmake(1) for more information on setting up the .dmakerc file.
powerhouse --> 1 job
/opt/SUNWspro/bin/dmake -f nbproject/Makefile-Debug.mk SUBPROJECTS= .build-conf

Build successful. Exit value 0.

Running "/usr/openwin/bin/xterm -e "/usr/avt/S1S12/netbeans-5.5.1/cnd1/bin/dorun.sh" -p "[Press Enter to close window]" -f "/var/tmp/nbcnd_rc30060" dist/Debug/Sun12-Solaris-Sparc/crashtest_1 " in /home/bild/SunStudioProjects/CrashTest_1

Run failed. Exit value 139.

Open in new window


Now, what this has done is create a core file, called "core" in the root of the project directory, i.e. SunStudioProjects\CrashTest_1.  

Debugging 'debug' core file through SunStudio

I then ask SunStudio to debug this core file, via Run->Debug COre File, choosing this core file, and leaving the "Executable" option as <from core>.  This launches SunStudio's DBX console window, in which is the output:

For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc
(dbx) debug - /home/bild/SunStudioProjects/CrashTest_1/core
Corefile specified executable: "/home/bild/SunStudioProjects/CrashTest_1/./dist/Debug/Sun12-Solaris-Sparc/crashtest_1"
Reading crashtest_1
core file header read successfully
Reading ld.so.1
Reading libCstd.so.1
Reading libCrun.so.1
Reading libm.so.1
Reading libc.so.1
Reading libdl.so.1
Reading libCstd_isa.so.1
Reading libc_psr.so.1
program terminated by signal SEGV (no mapping at the fault address)
Current function is main
(dbx) cd /home/bild/SunStudioProjects/CrashTest_1
(dbx) 

Open in new window


This has opened the source file CrashTest_1.cc, with the faulting line *p = 42 highlighted:

Source line being displayed
Debugging 'debug' core file through dbx in a terminal window

[bild@powerhouse ~/SunStudioProjects/CrashTest_1]$ dbx dist/Debug/Sun12-Solaris-Sparc/crashtest_1 core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.5' in your .dbxrc
Reading crashtest_1
core file header read successfully
Reading ld.so.1
Reading libCstd.so.1
Reading libCrun.so.1
Reading libm.so.1
Reading libc.so.1
Reading libdl.so.1
Reading libCstd_isa.so.1
Reading libc_psr.so.1
program terminated by signal SEGV (no mapping at the fault address)
Current function is main
   15       *p = 42;
(dbx)

Open in new window


Here you can see that the faulting line is shown to me.

Release configuration
I select the release configuration and hit build.  The following output is shown by SunStudio:

Running "/opt/SUNWspro/bin/dmake  -f Makefile CONF=Release" in /home/bild/SunStudioProjects/CrashTest_1

dmake: defaulting to parallel mode.
See the man page dmake(1) for more information on setting up the .dmakerc file.
powerhouse --> 1 job
/opt/SUNWspro/bin/dmake -f nbproject/Makefile-Release.mk SUBPROJECTS= .build-conf
powerhouse --> 1 job
mkdir -p build/Release/Sun12-Solaris-Sparc
CC    -c -xO3 -o build/Release/Sun12-Solaris-Sparc/CrashTest_1.o CrashTest_1.cc
powerhouse --> Job output
mkdir -p build/Release/Sun12-Solaris-Sparc
CC    -c -xO3 -o build/Release/Sun12-Solaris-Sparc/CrashTest_1.o CrashTest_1.cc
(/home/bild/SunStudioProjects/CrashTest_1)CrashTest_1.cc:
:(/home/bild/SunStudioProjects/CrashTest_1)CrashTest_1.cc
powerhouse --> 1 job
mkdir -p dist/Release/Sun12-Solaris-Sparc
CC    -g -o dist/Release/Sun12-Solaris-Sparc/crashtest_1 build/Release/Sun12-Solaris-Sparc/CrashTest_1.o  
powerhouse --> Job output
mkdir -p dist/Release/Sun12-Solaris-Sparc
CC    -g -o dist/Release/Sun12-Solaris-Sparc/crashtest_1 build/Release/Sun12-Solaris-Sparc/CrashTest_1.o  
(/home/bild/SunStudioProjects/CrashTest_1)build/Release/Sun12-Solaris-Sparc/CrashTest_1.o:
:(/home/bild/SunStudioProjects/CrashTest_1)build/Release/Sun12-Solaris-Sparc/CrashTest_1.o

Build successful. Exit value 0.

Open in new window


Again, I then run the binary through SunStudio.  I get the following output, and a nice window popup which contains the text

"Segmentation fault - core dumped"

Running "/opt/SUNWspro/bin/dmake  -f Makefile CONF=Release" in /home/bild/SunStudioProjects/CrashTest_1

dmake: defaulting to parallel mode.
See the man page dmake(1) for more information on setting up the .dmakerc file.
sunfire78 --> 1 job
/opt/SUNWspro/bin/dmake -f nbproject/Makefile-Release.mk SUBPROJECTS= .build-conf

Build successful. Exit value 0.

Running "/usr/openwin/bin/xterm -e "/usr/avt/S1S12/netbeans-5.5.1/cnd1/bin/dorun.sh" -p "[Press Enter to close window]" -f "/var/tmp/nbcnd_rc50156" dist/Release/Sun12-Solaris-Sparc/crashtest_1 " in /home/bild/SunStudioProjects/CrashTest_1

Run failed. Exit value 139.

Open in new window


Debugging 'release' core file through SunStudio

I then ask SunStudio to debug this core file, via Run->Debug COre File, choosing this core file, and leaving the "Executable" option as <from core>.  This launches SunStudio's DBX console window, in which is the output:

For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc
(dbx) debug - /home/bild/SunStudioProjects/CrashTest_1/core
Corefile specified executable: "/home/bild/SunStudioProjects/CrashTest_1/./dist/Release/Sun12-Solaris-Sparc/crashtest_1"
Reading crashtest_1
core file header read successfully
Reading ld.so.1
Reading libCstd.so.1
Reading libCrun.so.1
Reading libm.so.1
Reading libc.so.1
Reading libdl.so.1
Reading libCstd_isa.so.1
Reading libc_psr.so.1
program terminated by signal SEGV (no mapping at the fault address)
0x00010dcc: main+0x0004:        st       %o5, [0]
(dbx) cd /home/bild/SunStudioProjects/CrashTest_1

Open in new window


No opening of the source file.  Nothing other than the above.

Debugging 'release' core file through dbx in a terminal window

But first, evidence that the 'release' binary is not stripped:

[bild@sunfire78 ~/SunStudioProjects/CrashTest_1]$ file dist/Release/Sun12-Solaris-Sparc/crashtest_1
dist/Release/Sun12-Solaris-Sparc/crashtest_1:   ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped

Open in new window


[bild@sunfire78 ~/SunStudioProjects/CrashTest_1]$ dbx dist/Release/Sun12-Solaris-Sparc/crashtest_1 core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.5' in your .dbxrc
Reading crashtest_1
core file header read successfully
Reading ld.so.1
Reading libCstd.so.1
Reading libCrun.so.1
Reading libm.so.1
Reading libc.so.1
Reading libdl.so.1
Reading libCstd_isa.so.1
Reading libc_psr.so.1
program terminated by signal SEGV (no mapping at the fault address)
0x00010dcc: main+0x0004:        st       %o5, [0]
(dbx)

Open in new window


Clearly, no such luck with the faulting line being displayed.  

I would like to restress that the only reason I am debugging manually via a terminal window is to try to determine if SunStudio is doing something wrong when it tries to debug the release core file: clearly, the easiest thing to do is always debug via the IDE, but when that stopped working for the 'release' binary, I decided to try alternatives; dbx from the command line being that alternative.  However, in theory it should not matter, since all SunStudio does is call dbx anyway, so something is clearly going wrong with this binary.

Hopefully this detailed description can shed some light on what is going on.

Thank again.
Principle Software Engineer
BRONZE EXPERT
Commented:
The problem here is what I said above. The although the release executable is linked with the -g flag, the object files are compiled with -xO3.  Thus, no debug output is produced during the compilation. To get the debug info, all stages must use -g. This tells the compiler to produce the info, and it tells the linker to copy it to the executable. With the -g only on the linker, it will try to copy the info, but it doesn't find any to copy.

If you change the -xO3 in the CFLAGS for the release Makefile, you will get the debug info, but you will
not get the code optimizations.

One other thing to consider, since you do get the address of the instruction where the failure occurred, it is possible to use the "dis" command (command line, not dbx) to help figure out what the source code was that caused the error. If the executable is unstripped, you should have no trouble figuring out what function it was in, and then you can use the disassembled code to figure out where in the function the problem was. I do this all the time. It is not fun or as efficient as having the debug info, but it is doable.
Michael EagerConsultant
Commented:
The release version is built without -g:
   CC    -c -xO3 -o build/Release/Sun12-Solaris-Sparc/CrashTest_1.o CrashTest_1.cc

No debug info is generated.  When you debug this version, you will not be shown source information.

Nothing is wrong with the binary.  Sun Studio follows an old development model (as does Microsoft Visual Studio). There are two versions:  an unoptimized debug version which supports source level debugging and an optimized release version which does not.  

Author

Commented:
blu - OK.  I am sorry that I did not register your original solution - the presence of -xO3 instead of -g.

eager - thank you for clarifying.

Both -

When I modify the release makefile to have

$(COMPILE.cc) -g -o ${OBJECTDIR}/CrashTest_1.o CrashTest_1.cc

Open in new window


instead of

$(COMPILE.cc) -xO3 -o ${OBJECTDIR}/CrashTest_1.o CrashTest_1.cc

Open in new window


I can debug the binary through both SunStudio and via a terminal/DBX.

Before I close this, I would like to ask one more thing: I noticed in the project properties/source file properties window that there are various "Development modes": thse include "Fast Build", "Debug", "Performance Debug", "Test Coverage", "Diagnosable Release", "Release" and "Performance Release".  "Diagnosable Release" sounded good -  however, I changed it but I still don't get the -g option added.  The output from dbx does not highlight the faulting line, but it does give me more than "Release":

Reading crashtest_1
core file header read successfully
Reading ld.so.1
Reading libCstd.so.1
Reading libCrun.so.1
Reading libm.so.1
Reading libc.so.1
Reading libdl.so.1
Reading libCstd_isa.so.1
Reading libc_psr.so.1
program terminated by signal SEGV (no mapping at the fault address)
Current function is main (optimized)
   13   int main(int argc, char** argv) {

Open in new window


The difference in the makefile is quite subtle:

Release:
$(COMPILE.cc) -xO3 -o ${OBJECTDIR}/CrashTest_1.o CrashTest_1.cc

Open in new window


Diagnosable Release:
$(COMPILE.cc) -g0 -xO2 -o ${OBJECTDIR}/CrashTest_1.o CrashTest_1.cc

Open in new window


Changing to "Performance Release" gives me a very similar result to "Release": no highlighting of the problematic source line.

Why has Sun made it so difficult (difficult in the sense of having to manually edit a makefile that clearly says "do not edit!") to meaningfully debug a release mode binary???

blu - a second question for you, since you mention 'dis' (I have added another 50 points just for you if you can answer me this): when I run 'dis' on my binary, I get a lot of information displayed, I take it that the useful bit is

main()
        10dc8:  90 10 20 00        clr          %o0
        10dcc:  9a 10 20 2a        mov          42, %o5
        10dd0:  81 c3 e0 08        retl
        10dd4:  da 20 20 00        st           %o5, [0x0]

Open in new window


Now, if I did not have dbx tell me that the error was

0x00010dd4: main+0x000c:        st       %o5, [0]

Open in new window


I would have to search all the addresses shown down the left hand side in the output of 'dis' to find the one closest to 0x00010dd4, right?

Also, where you say "and then you can use the disassembled code to figure out where in the function the problem was." I take it you are reffering to understanding the assembly instructions (clr, mov, retl, st), or is there some magic that we can do in order to get the source line from
main+0x000c:        st       %o5, [0]

Open in new window

?

Thanks again.
Brian UtterbackPrinciple Software Engineer
BRONZE EXPERT

Commented:
The only trick that I use to help me figure out the mapping from source lines to assembly code is to look at the "call" lines. The function calls near a given line of source code are indicative, if not unique. This often helps, but sometimes it doesn't help at all. It depends on your code.

I issue with the different make files is that you have a choice between better debugging and better optimizations. The makefile targets attempt to provide intermediate choices and meaningful thresholds. As more optimizations are used, the less the resulting generated code resembles the original source code. Once while debugging optimized code I realized that similar blocks of code from three different functions were replaced by a single block of code in the generated code. This block of code was positioned in such a way as to reduce cache misses for all three functions. Thus large sections of the source code had no mapping at all to the generated code.
Michael EagerConsultant

Commented:
The compiler can generate debugging information (controlled by -g) independent of whether you have specified optimization.

Sometimes it is easier to debug a program which has not been optimized.  When the compiler optimizes code, it frequently reorders code so that when you step through your program, it will appear to jump from line to line, apparently randomly.  

Sun provides you with the "plain debug" option, so that stepping through your program is essentially sequential.  The "release" option generates an optimized program without debug information, which is good for production releases, especially when you don't want someone to reverse engineer your application.  The "diagnosable release" optimizes the program but also generates debug info.  This makes it much easier to debug a production program.  

You should not need to edit the makefile manually.  Everything should be available from the GUI.

Author

Commented:
OK.  Thanks both.  

I can only get a "Performance Release" config to generate debug info when built totally through the IDE: the "Release" just will not have it.  I achieved this by specifying -g on the "Additional Options" section of the command line pages, with "Performance Release" selected, for both project and source file.  I don't know why this is and am frankly getting a little frustrated with SunStudio.  

Explore More ContentExplore courses, solutions, and other research materials related to this topic.