From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 BuildID: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 dbx can't find .o file and load debug info automatically Reproducible: Always Steps to Reproduce: 1.build a mozilla according to the standard progress. 2.use workshop to debug mozilla-bin 3.while loading or running, it always reports "can't find file xxx...". actually, it a .o file that contains debug information 4.can't set break points in some files Actual Results: can't set break points in some files Expected Results: can automatically load those .o file and then set breakpoints seems happens on new code base (1.0+) ?
Confirming bug based on the fact that I have given workarounds to ~10 Sun engineers in the last couple of months for this issue (and I am punished by it, too) ...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Created attachment 84644 [details] [diff] [review] Set MKSHLIB_UNFORCE_ALL so that archive libs are used when linking Roland claimed that our method of extracting objects from the archives to create shared libs was the reason for the dbx woes. This patch should fix that problem but I have no idea if it'll fix the dbx issue.
Priority: -- → P3
Target Milestone: --- → mozilla1.0.1
This did not fix the problem. Roland - it may be a good idea to post your workaround in this bug. Unfortunately, i could not get any response about this from the Compiler group of SUN.
Prabhat Hegde wrote: > This did not fix the problem. Roland - it may be a good idea to post your > workaround in this bug. OK, two workarounds in the next two comments... > Unfortunately, i could not get any response about this from the Compiler > group of SUN. CC:'ing the usual suspects... :)
Workaround 1: Compile the whole source with the compiler option "-xs" (e.g. % export CC="/opt/SUNWspro/FD7/bin/cc -xs" CXX="/opt/SUNWspro/FD7/bin/CC -xs" # before running "configure"). This will put the debug info into the executables. Side-effect: - Larger objdir/ and binaries - "dbx" wants more memory - expect that it get nearly as hungry as GDB... =:-)
Workaround 2: Try running mozilla/dbx like this: -- snip -- % cd dist/bin % ./run-mozilla.sh /opt/SUNWspro/FD7/bin/dbx $(find ../.. -type d | while read i ; do echo "-I $i " ; done) ./mozilla-bin -- snip -- This adds _all_ obj dirs to dbx's search path... Side-effect: - Expect that the disk activity will increase a lot (tuning the kernel (DNLC etc.) may be a good idea in this case) - This workaround may not work if two or more object files have the same name - Older versions (~~WS5.0) of Sun Workshop "dbx" may have problems with large argument lists
To explain my theory about what is going wrong here: We create object files (*.o) and pack them into ar-archives (*.a) as an intermediate step and then later create the shared libraries (*.so) from these archives. I assume that somehow "dbx" gets confused by the intermediate step (since it searches the *.o files in the dir where the *.a archives are placed) ... getting rid of this and creating the *.so libraries directly from the *.o files should fix the issue.
Yes, Roland. You are quite right on #7. What I do to resolve this problem is to create symbol links for all the *.o files in that module's "build" directory. Is that stupid?=( . But it is a easy way if I only want to debug into a few .o files like that. I have found that dbx can do pathmap, but it can only map one directory and not too much helpful. :-(
Skipping the intermediate archive libraries has been discussed a number of times. As bug 11219 will point out, one of the main things preventing us from seriously considering that approach is the posix 4k char limit for command lines. At last count, even with symlinking, the cmdline used to link layout was well over 6k.
Target Milestone: mozilla1.0.1 → Future
Gilbert Fang wrote: > I have found that dbx can do pathmap, but it can only map one directory and > not too much helpful. :-( Did you try the workarounds in comment #5 or comment #6 (minor tuning of the DNLC kernel settings may improve the perf. if you use that workaround :) yet ?
Christopher Seawood wrote: > Skipping the intermediate archive libraries has been discussed a number of > times. As bug 11219 will point out, one of the main things preventing us > from seriously considering that approach is the posix 4k char limit > for command lines. > At last count, even with symlinking, the cmdline used to link layout was well > over 6k. Do Sun Workshop builds break at the 4k barrier or would the build finish without problems ? If WS6 works - what about adding a "configure" switch to (optionally) skip the intermediate archives and pass everything in one step to the linker ? BTW: The intermediate archives are causing more problems than simple "dbx confusion" - they are breaking "xipo" (e.g. the interprocedural optimizer) builds, too... ;-((
new information: in a debug version, ./run-mozilla.sh -g -d dbx ./xpcshell js>load("driver.js") mozilla crashed at: Reading libautoconfig.so t@1 (l@1) signal SEGV (no mapping at the fault address) in nsGenericFactory::GetHelperForLanguage dbx: warning: can't find file "/export/browser/simford/new-build/src/build1205/mozilla/xpcom/build/nsGenericFactory.o" dbx: warning: see `help finding-files' at 0xff178100 0xff178100: GetHelperForLanguage+0x0004: ld [%o0 + 0x2c], %g4 Current function is XPCWrappedNative::GatherProtoScriptableCreateInfo (optimized) 563 nsresult rv = classInfo->GetHelperForLanguage(
driver.js is from timeless, nsGenericFactory.o is in mozilla/xpcom/glue
Roland: it is a little related. it just wants to tell us another situation that "dbx can't find .o file" during debug, dbx complains "can't find mozilla/xpcom/build/nsGenericFactory.o" but actually, nsGenericFactory.o is located in mozilla/xpcom/glue
Mass reassign to new default build assignee
Assignee: seawood → mozbugs-build
Priority: P3 → --
Mass reassign of Build/Config bugs to Leaf.
Assignee: mozbugs-build → leaf
Target Milestone: Future → ---
Assignee: leaf → roland.mainz
We have two options here: 1. Fix "dbx" 2. Build debug builds with "-g -xs" instead of "-g". This has the disadvantage that it maks dbx horrible resource hungry. I would prefer  if possible - but if noone from the Sun Compiler team looks at the issue we may have to implemement .
This sounds like a dbx bug, I'll try to find it and fix it. It is too late to fix for Sun Studio 9 release, but I can try to fix it in the release after that. We are considering transitioning from stabs to dwarf format for debug data, but we don't have a way to leave the dwarf info in the .o files. We currently have to turn on -xs when we use dwarf. Is the stabs-in-objfiles feature a big reason to prefer using cc/dbx instead of gcc/gdb? What if we had a utility that could shrink the information after it was put into a library or executable? That would solve most of the dbx startup time problem, but not the disk-space problem. note that -xs doesn't make the .o files any bigger, just the binaries and libraries. I'll let you know what I find out about the dbx bug. --chris
I made a little test case where a .a files gets turned into a .so file, and then linked with a program. Dbx seems to find everything as long as you don't move any of the parts. I can remove the .o files, and dbx will still get them from inside the .a file. If I remove the *directory* that the .o files were built in, then dbx complains that it can't find the source file. (This seems to be different from the original complaint) This happens because dbx tries to read: $FULL_PATH_OF_PROGRAM/$RELATIVE_PATH_TO_OBJ/$RELATIVE_PATH_TO_SRC The stepping stones fail to find the source, if the obj directory is deleted or renamed. I need more information to proceed: 1. which version of compilers are being used 2. which version of dbx is being used 3. which files and directories are being moved or removed (if any) as a part of the build process
Chris Quenellewrote: > I made a little test case where a .a files gets turned into a .so > file, and then linked with a program. Dbx seems to find everything > as long as you don't move any of the parts. Did you try: 1. Create archive a1.a, a2.a (all in seperate dirs) 2. Create archive b1.a, b2.a (all in seperate dirs) 3. Build archive a.a from a1.a and a2.2 4. Build archive b.a from b1.a and b2.2 5. Link final x.so from a.a and b.a
How do I make an archive from an archive? Do you mean put the first archive inside the second archive? Or extract all the .o's from the first archive and put them in the second archive? Does the Mozilla process end up removing or moving any of the intermediate files or directories? --chris
Is this still a problem? Can anyone create a smaller test case that shows the same problem? Or can you explain exactly what the build steps are that cause the bug? It's possible this could be worked around using pathmap, if I knew what the specific problem was. Actually, using the -xs option should not cause dbx to use that much more memory. Even when all stabs are in the executable, they are still read "on demand", one object file at a time, when needed. If your build environment does a lot of copying/moving of object files and archive libraries, then the best long-term plan would be to compile with -xs. When the compilers finish moving to dwarf, all binaries will act as if -xs had been supplied. Dwarf requires linker relocation to make sense, and so it won't support leaving information only in the .o files. This will make the the a.out files larger on disk, but the memory footprint of the a.out program, and the memory footprint of dbx should not increase.
Assignee: roland.mainz → nobody
Component: Build Config → Build Config
Product: SeaMonkey → Core
QA Contact: granrosebugs → build-config
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.