Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 8840689
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: June 14, 20262026-06-14T10:31:16+00:00 2026-06-14T10:31:16+00:00

I have GDB 7.5 installed in my machine. It seems pretty-printers for STL already

  • 0

I have GDB 7.5 installed in my machine. It seems pretty-printers for STL already comes bundled with this version, since running:

(gdb) info pretty-printers

prints a long list of all available STL printers.

Debugging a C++ code that has been compiled with g++ gets the correct behaviour of pretty printing. However, the same is not observed if the same code is compiled with clang++.

Below is an output when I run gdb:

BFD: /usr/lib/libstdc++.6.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/libstdc++.6.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/libSystem.B.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/libSystem.B.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/libc++abi.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/libc++abi.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libcache.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libcache.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libcommonCrypto.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libcommonCrypto.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libcompiler_rt.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libcompiler_rt.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libcopyfile.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libcopyfile.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libdispatch.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libdispatch.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libdnsinfo.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libdnsinfo.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libdyld.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libdyld.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libkeymgr.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libkeymgr.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/liblaunch.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/liblaunch.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libmacho.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libmacho.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libquarantine.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libquarantine.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libremovefile.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libremovefile.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libsystem_blocks.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libsystem_blocks.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libsystem_c.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libsystem_c.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libsystem_dnssd.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libsystem_dnssd.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libsystem_info.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libsystem_info.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libsystem_kernel.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libsystem_kernel.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libsystem_m.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libsystem_m.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libsystem_network.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libsystem_network.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libsystem_notify.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libsystem_notify.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libsystem_sandbox.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libsystem_sandbox.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libunc.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libunc.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libunwind.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libunwind.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libxpc.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libxpc.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/system/libcorecrypto.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/system/libcorecrypto.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/libobjc.A.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/libobjc.A.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/libauto.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/libauto.dylib(i386:x86-64): unknown load command 0x2b
BFD: /usr/lib/libc++.1.dylib(i386:x86-64): unknown load command 0x2a
BFD: /usr/lib/libc++.1.dylib(i386:x86-64): unknown load command 0x2b

I would like to know how I can get STL containers pretty-printed when the code was compiled with clang++?
Note that I can debug the application; I just cannot pretty print the STL contents.

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-06-14T10:31:17+00:00Added an answer on June 14, 2026 at 10:31 am

    The gdb you’re using has a list of known Mach-O load command numbers but two new ones were added in Mac OS X 10.8 (LC_SOURCE_VERSION, 0x2a and LC_DYLIB_CODE_SIGN_DRS, 0x2b) and it is complaining that it doesn’t know about these. It doesn’t need to know about these, there’s nothing necessary for the debugger in these load commands. The warnings should be harmless.

    You’re far better off using either the Apple provided gdb (which doesn’t have python support, I know) or using the new debugger supported by Apple, LLDB. lldb is a pretty exciting new debugger that is improving rapidly, Apple has been developing it from scratch (leveraging llvm’s existing infrastructure and features as much as possible) over the past few years and it is quite capable today. It was designed from the beginning to be extendable via Python and it is easy to create new data formatters for container types that you may come across.

    If you haven’t used lldb before, but are familiar with gdb, a useful cheat sheet is the command equivalences page over at http://lldb.llvm.org/lldb-gdb.html

    Give lldb a try. It’s the future of supported debugging on Mac OS X – there’s a lot there to like today and it’s getting better every release. It’s also open source, you can check it out from http://lldb.llvm.org/ and play with it yourself.

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

I have installed GDB 7.0 and python per the following instructions . In the
I am trying to debug a segfault, and I have this output from gdb:
We have installed GDB on AIX 6.1 (gdb-6.0-1.aix5.1.ppc_AIX.rpm) and I notice that there is
I have looked for documentation on this and found nothing. I have MinGW installed
I have been struggling to understand how this works for a while in gdb
I have a gdb backtrace on it that yields this: #0 match_at (reg=0xcce4a00, str=0xd47b101
I have a program and want to debug it in gdb. Will I see
i have a char buffer[100] and i'm trying to use gdb to read the
When I start GDB from the command line I have no problems. But when
I'm outside gdb's target executable and I don't even have a stack that corresponds

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.