Re: [Gdb] debug level versus size

[Charles Manning]

Much of the size is likely due to the inclusion of debug symbol information 
in the executable.

Use objdump or similar to see what actual changes have happened in the 
executable part of the file.

One trick is to only compile the parts you want to debug without optimisation 
and leave the rest optimised.



On Saturday 08 January 2005 00:40, Bahadir Balban wrote:
> Hi,
>
> I have a buggy executable and to figure out the bug I needed to use a
> stack trace. For this purpose I compiled my application with debug
> support but the exe size is 94,5MB compared to optimised one that is
> 7,4MB. Unfortunately I cannot run it now due to insufficient memory.
>
> What flags/configure options should I use to get an exe capable of
> giving a meaningful stack trace with a smaller binary size?
>
> I used the following configure options for the large debug-enabled binary:
>
> # code generation options (optimize for size)
> #ac_add_options --enable-optimize=-Os
> #ac_add_options --enable-strip
> #ac_add_options --disable-debug
> ac_add_options  --enable-debug
> #ac_add_options --enable-reorder
> #ac_add_options --enable-elf-dynstr-gc
>
> #ac_add_options --disable-dtd-debug
> ac_add_options --enable-dtd-debug                   # ENABLE DTD DEBUG
> ac_add_options --disable-logging
> ac_add_options --disable-tests
>
> # enable static build (exists for both debug and non-debug)
> ac_add_options --disable-shared
> ac_add_options --enable-static
>
> which resulted in the following flags during compilation:
>
> -DDEBUG -D_DEBUG -D_DEBUG_root -D_TRACING and -g.
>
> Many thanks,
> Bahadir
>
>
> _______________________________________________
> Gdb mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gdb