As Antoine said, debug mode is probably the most important configuration. You can also try the `relwithdebinfo` if you're trying to debug the optimized code. I'd also add the following:
1. Building out of conda provides a much better integration with gdb and the system's libstdc++ due to the pretty printers for common container classes. This may download a lot of source packages. 2. Sometimes, you have to let the test run and fail once, then set a breakpoint such that gdb will get the sources by looking at the loaded shared libraries. François On Mon, Jun 15, 2020 at 10:38 AM Antoine Pitrou <anto...@python.org> wrote: > > > Hi Maarten, > > You should build in debug mode, i.e. pass -DCMAKE_BUILD_TYPE=Debug > > Regards > > Antoine. > > > Le 15/06/2020 à 16:35, Maarten Breddels a écrit : > > Hi all, > > > > I have trouble getting gdb working with a test suite. > > Running e.g.: > > $ gdb ./release/arrow-compute-scalar-test > > I can't set a breakpoint on e.g. > > arrow::compute::internal::TransformAsciiUpper in > > arrow/compute/kernels/scalar_string.cc. > > Tab completion on arrow::compute::int<tab> give no tab completion, because > > I assume this is not exported (although the symbol is visible using nm > > path/to/libarrow.so.100). > > Is there an easy (or hard?) way to get a breakpoint there, and what might > > be the reason I cannot put a breakpoint at TransformAsciiUpper. > > > > cheers, > > > > Maarten Breddels > >
