Closed Bug 146154 Opened 22 years ago Closed 15 years ago

dbx can't find .o file and load debug info automatically

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Platform:
Sun
Solaris
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: calvin.liu, Unassigned)

Details

Attachments

(1 file)

Set MKSHLIB_UNFORCE_ALL so that archive libs are used when linking
699 bytes, patch
Details | Diff | Splinter Review 
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
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
Simford:
How are comment #12 and comment #13 related to this bug ?

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 → ---
Taking myself...
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 [1] if possible - but if noone from the Sun Compiler team looks
at the issue we may have to implemement [2].
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
Product: Browser → Seamonkey
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
Product: SeaMonkey → Core
QA Contact: granrosebugs → build-config
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: