#34831 closed defect (fixed)
eliminate missing symbols from gdb compatible compilers
| Reported by: | seanfarley (Sean Farley) | Owned by: | jeremyhu (Jeremy Huddleston Sequoia) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.1.1 |
| Keywords: | Cc: | mww@…, erickt@…, tenomoto (Takeshi Enomoto), nonstop.server@…, su-v, darylew@…, cooljeanius (Eric Gallager) | |
| Port: | apple-gcc40 apple-gcc42 gcc42 gcc43 gcc44 gcc45 gcc46 gcc47 gcc48 clang-2.9 clang-3.0 clang-3.1 clang-3.2 dragonegg-3.0 dragonegg-3.1 dragonegg-3.2 llvm-2.9 llvm-3.0 llvm-3.1 llvm-3.2 llvm-gcc42 g95 |
Description
The hundreds of lines of output of missing object files causes much grief and, in some cases, will prevent debugging entirely.
The goal of this patch is to completely get rid of all warnings and errors due to missing symbols. The importance of this is high since all compilers are effected and this in turn affects *any* user compiled code.
For compilers that are gdb compatible (c, c++, and fortran), the portfile needs to keep the debug symbols. This patch fixes dsymutil being called for apple-gcc4{0,2}, gcc4{2,3,4,5,6,7,8}, {clang,llvm}-{2.9,3.0,3.1}, llvm-gcc42, g95, and dragonegg-3.{0,1,2}. Alternatively, as suggested by Jeremy, each portfile could strip the symbols from the compiler's shared libraries. This could work but I don't know how to implement this method off the top of my head.
Attached to this ticket is:
1) patch that calls dsymutil for each port
2) a simple test program
3) the gdb output of (2)
Attachments (4)
Change History (24)
Changed 12 years ago by seanfarley (Sean Farley)
| Attachment: | dsymutil.patch added |
|---|
comment:4 Changed 12 years ago by mf2k (Frank Schima)
| Owner: | changed from macports-tickets@… to jeremyhu@… |
|---|---|
| Port: | apple-gcc40,apple-gcc42,gcc42,gcc43,gcc44,gcc45,gcc46,gcc47,gcc48,clang-2.9,clang-3.0,clang-3.1,clang-3.2,dragonegg-3.0,dragonegg-3.1,dragonegg-3.2,llvm-2.9,llvm-3.0,llvm-3.1,llvm-3.2,llvm-gcc42,g95 → apple-gcc40 apple-gcc42 gcc42 gcc43 gcc44 gcc45 gcc46 gcc47 gcc48 clang-2.9 clang-3.0 clang-3.1 clang-3.2 dragonegg-3.0 dragonegg-3.1 dragonegg-3.2 llvm-2.9 llvm-3.0 llvm-3.1 llvm-3.2 llvm-gcc42 g95 |
comment:5 follow-up: 6 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
No, using dsymutil is not the answer. E
See #34491:
If you want to debug gcc47's runtime bits, then use '-k' to keep those object files around. If you are just concerned about the messages printed by gdb, then perhaps we should just strip those object files.
comment:6 Changed 12 years ago by seanfarley (Sean Farley)
Replying to jeremyhu@…:
See #34491:
If you are just concerned about the messages printed by gdb, then perhaps we should just strip those object files.
Right, but how does one safely do that?
comment:7 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
See the man page for strip, or use -s if you use install.
Changed 12 years ago by seanfarley (Sean Farley)
| Attachment: | strip.patch added |
|---|
strip debug symbols from compilers
comment:8 Changed 12 years ago by seanfarley (Sean Farley)
This turned out to be easier than I thought it would be. The hardest part was compiling *every* compiler to test. I tested each C and Fortran compiler and all versions worked. There were no warning messages and no hanging when attaching a debugger. Let me know if this version of the patch (strip.patch) works for MacPorts.
comment:9 follow-up: 10 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
I am going to be gone for 2 weeks, but this looks good to me if someone else wants to commit the strip.patch
comment:10 Changed 12 years ago by seanfarley (Sean Farley)
Replying to jeremyhu@…:
I am going to be gone for 2 weeks, but this looks good to me if someone else wants to commit the strip.patch
Any update for getting strip.patch committed?
comment:11 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Yeah, I was on vacation for a month and came back to an inbox 1-month long. You will need to be patient, sorry. I'll get to these issues based on priority, or someone else can certainly commit it if they are willing to test.
comment:12 Changed 12 years ago by seanfarley (Sean Farley)
Gotcha. No worries, I was just checking in :-)
comment:13 Changed 12 years ago by jmroot (Joshua Root)
| Cc: | mww@… erickt@… mfeiri@… takeshi@… added |
|---|
comment:14 Changed 12 years ago by mfeiri
| Cc: | mfeiri@… removed |
|---|
comment:15 follow-up: 16 Changed 12 years ago by tenomoto (Takeshi Enomoto)
Committed the patch for g95 in r101293.
comment:16 Changed 12 years ago by seanfarley (Sean Farley)
comment:18 Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)
I should roll this into the libgcc changes.
comment:19 Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
r109291 should take care of this.
comment:20 Changed 7 years ago by RJVB (René Bertin)
Am I right that this modification and the stripping of port:libgcc's libraries is relevant only for OS versions where gdb is the default debugger?
EDIT: yes, it is. A quick check with unstripped libgcc libraries (but without their .o files) shows that lldb doesn't mind.
gdb on the other hand still minds, but it also complains about missing object files from all other shared libraries being pulled in. But in my experience it isn't usable on OS X 10.9 (and later, undoubtedly). I'd propose to drop the stripping for ${os.major} >= 13 as that information could have its use. I'll include that in my proposed modifications to port:libgcc (and port:gcc7).
call dsymutil for each gcc-derived port