[PATCH] GDB: maint: Fix build on FreeBSD

[PATCH] GDB: maint: Fix build on FreeBSD

[Thiago Jung Bauermann]

While trying to build current trunk of GDB on FreeBSD 14.3 on aarch64,
I hit this warning converted to an error:

In file included from /home/bauermann/src/binutils-gdb/gdb/maint.c:37:
/home/bauermann/src/binutils-gdb/gdb/maint.h:64:8: error: private field 'm_start_space' is not used [-Werror,-Wunused-private-field]
   64 |   long m_start_space;
      |        ^
1 error generated.
gmake[2]: *** [Makefile:1973: maint.o] Error 1

I used the default compiler on this system:

$ c++ --version
FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2)
Target: aarch64-unknown-freebsd14.3
Thread model: posix
InstalledDir: /usr/bin

The problem is that the only two places that use m_start_space are
guarded by HAVE_USEFUL_SBRK, so also guard the member declaration with
it.

Build-tested on aarch64-unknown-freebsd14.3.
---
 gdb/maint.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gdb/maint.h b/gdb/maint.h
index cccb6f60354f..693001801b2c 100644
--- a/gdb/maint.h
+++ b/gdb/maint.h
@@ -61,7 +61,9 @@ class scoped_command_stats
   bool m_symtab_enabled : 1;
   run_time_clock::time_point m_start_cpu_time;
   std::chrono::steady_clock::time_point m_start_wall_time;
+#ifdef HAVE_USEFUL_SBRK
   long m_start_space;
+#endif
   /* Total number of symtabs (over all objfiles).  */
   int m_start_nr_symtabs;
   /* A count of the compunits.  */

Re: [PATCH] GDB: maint: Fix build on FreeBSD

[Simon Marchi]

On 6/27/25 12:45 AM, Thiago Jung Bauermann wrote:
> While trying to build current trunk of GDB on FreeBSD 14.3 on aarch64,
> I hit this warning converted to an error:
> 
> In file included from /home/bauermann/src/binutils-gdb/gdb/maint.c:37:
> /home/bauermann/src/binutils-gdb/gdb/maint.h:64:8: error: private field 'm_start_space' is not used [-Werror,-Wunused-private-field]
>    64 |   long m_start_space;
>       |        ^
> 1 error generated.
> gmake[2]: *** [Makefile:1973: maint.o] Error 1
> 
> I used the default compiler on this system:
> 
> $ c++ --version
> FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2)
> Target: aarch64-unknown-freebsd14.3
> Thread model: posix
> InstalledDir: /usr/bin
> 
> The problem is that the only two places that use m_start_space are
> guarded by HAVE_USEFUL_SBRK, so also guard the member declaration with
> it.
> 
> Build-tested on aarch64-unknown-freebsd14.3.

I think there is nothing wrong with fixing the build, so:

Approved-By: Simon Marchi <simon.marchi@efficios.com>

But then, is this feature useful at all nowadays?  I don't have a deep
knowledge of memory allocators work, but my understanding is that modern
allocators use mmap to obtain more memory from the system (or they use
both).  So the memory usage computed using sbrk would not be very
accurate.  All of this to say that, if there is a metric we know is not
accurate, it might be better to remove it.

Simon

Re: [PATCH] GDB: maint: Fix build on FreeBSD

[Thiago Jung Bauermann]

Hello Simon,

Simon Marchi <simark@simark.ca> writes:

> On 6/27/25 12:45 AM, Thiago Jung Bauermann wrote:
>> While trying to build current trunk of GDB on FreeBSD 14.3 on aarch64,
>> I hit this warning converted to an error:
>> 
>> In file included from /home/bauermann/src/binutils-gdb/gdb/maint.c:37:
>> /home/bauermann/src/binutils-gdb/gdb/maint.h:64:8: error: private field 'm_start_space' is not used [-Werror,-Wunused-private-field]
>>    64 |   long m_start_space;
>>       |        ^
>> 1 error generated.
>> gmake[2]: *** [Makefile:1973: maint.o] Error 1
>> 
>> I used the default compiler on this system:
>> 
>> $ c++ --version
>> FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2)
>> Target: aarch64-unknown-freebsd14.3
>> Thread model: posix
>> InstalledDir: /usr/bin
>> 
>> The problem is that the only two places that use m_start_space are
>> guarded by HAVE_USEFUL_SBRK, so also guard the member declaration with
>> it.
>> 
>> Build-tested on aarch64-unknown-freebsd14.3.
>
> I think there is nothing wrong with fixing the build, so:
>
> Approved-By: Simon Marchi <simon.marchi@efficios.com>

Thanks! Pushed as commit 48e0ec748443.

> But then, is this feature useful at all nowadays?  I don't have a deep
> knowledge of memory allocators work, but my understanding is that modern
> allocators use mmap to obtain more memory from the system (or they use
> both).  So the memory usage computed using sbrk would not be very
> accurate.  All of this to say that, if there is a metric we know is not
> accurate, it might be better to remove it.

I don't know much either, but my cursory research suggests you're right.

OTOH I would think it should be possible to obtain a "memory allocated
by GDB" number to use in place of the sbrk return result, so at least on
some platforms this metric can be fixed. For example, glibc provides the
malloc_info function, and Unix in general can use RSS.

Not that I'm volunteering to fix this code. :-)

-- 
Thiago