This is the mail archive of the
mailing list for the GDB project.
Fwd: [gnu.org #1159319] gdb mailing list
- From: Amit Chaudhuri <amit dot k dot chaudhuri at gmail dot com>
- To: gdb at sourceware dot org
- Date: Mon, 7 Nov 2016 19:43:25 +0000
- Subject: Fwd: [gnu.org #1159319] gdb mailing list
- Authentication-results: sourceware.org; auth=none
- References: <RT-Ticketfirstname.lastname@example.org> <CAH=VbNcYjar+EanKBhVjdEfC-gDOKX-qrLZ6dQ3S10O22uzTcw@mail.gmail.com> <email@example.com>
after this respnse from Jeanne Rasata via RT <firstname.lastname@example.org>.
Are you able to help me work out whether there's a problem with my
email account getting questions through to a suitable gdb technical
Original text in line below.
** Original text below **
** Background **
I've recently run into a situation where debugging using gdb/gdbserver
(as opposed to debugging a core file) stopped working. After a little
research we worked out that a kernel parameter was responsible for the
total failure of single stepping. We were able to set a breakpoint on
a test application, but any attempt to step (or stepi) was instantly
met with application termination and a message about SIGTRAP.
The processor we are using is a freescale qoriq (so powerpc) and the
kernel parameter was CONFIG_DEBUG_CW. The toolchain was from the 1.9
version of the QorIQ SDK from the processor supplier which contains
(powerpc-fsl-linux-gnuspe-)g++ 4.9.2 and
(powerpc-fsl-linux-gnuspe-)gdb 7.8.1. Linux kernel version is 3.12.37.
After turning off the offending parameter and rebuilding the kernel
single stepping now works. Which brings me to the remaining problem;
one I find a little odd.
** Problem **
Using gdbserver/gdb I am able to set breakpoints, hit them and single
step in trivial, single threaded test applications in both C and C++.
Using the same set up but a larger (113M stripped), multi-threaded C++
application breakpoints that should be hit are not firing. When I set
a breakpoint, info br reports the correct location, and list shows
source code as I would expect. Further, info br shows the bp to be
Reading other material on this list, I've tentatively concluded that
some some reason breakpoints are not being inserted on the target.
I'm looking for ideas on how to isolate (and overcome) the cause of
this. Is it possible that the size of the application's address space
is hitting some sort of internal limit that results in gdb failling to
insert the bp? Are there flags I can pass to gdb to get a better idea
of why my bps are not firing? Are there kernel configuration
parameters for PPC that might explain this? The following have me
TIA - Regards,
Footnote: earlier toolchains (with different limitations and much
earlier version of all components) were able to do this.
---------- Forwarded message ----------
From: Jeanne Rasata via RT <email@example.com>
Date: Mon, Nov 7, 2016 at 1:30 PM
Subject: [gnu.org #1159319] gdb mailing list
Please forgive this tardy response to your message!
> [firstname.lastname@example.org - Fri Oct 28 03:12:20 2016]:
> I'm trying to post a question to the gdb mailing list from the cc'd
> email address above. It is possible my first attempt was before
> registering, but a second attempt was definitely after registration
> and confirmation.
> I can't see anything that says that questions to the list are
> moderated and that mine is in a queue. It does not appear in the
> October 2016 listing in the archive at
> Is there some problem with my email that means my question is being
> bounced? Have I missed something important somewhere along the way.
> Great tool - btw. Any advice appreciated.
Hm, I'm not sure why your message was not listed. Unfortunately, this
is only the general e-mail contact for the FSF and the GNU Project and
I am unable to answer technical questions. Please contact the
GDB-support folks (contact info listed at
http://directory.fsf.org/wiki/Gdb#tab=Details), as they will be able
to determine what the problem is.
Thank you for supporting free software.
Free Software Foundation
GnuPG Key: F24B 3F64 31A1 90D6 1CCC 0394 E8FD 48A0 DE0D C371
Have we been helpful to you today? Would you like to help
the FSF continue to spread the word about software freedom?
You too can become a member! Learn more at: