On Wed, Jun 12, 2024 at 6:11 PM Ross Burton <ross.bur...@arm.com> wrote: > > On 12 Jun 2024, at 12:38, Kaiwan N Billimoria <kaiwan.billimo...@gmail.com> > wrote: > > > > On Wed, Jun 12, 2024 at 4:43 PM Ross Burton <ross.bur...@arm.com> wrote: > >> > >> On 12 Jun 2024, at 11:44, Kaiwan N Billimoria via lists.yoctoproject.org > >> <kaiwan.billimoria=gmail....@lists.yoctoproject.org> wrote: > >>> > >>> Hello all! > >>> > >>> I have a newbie question regarding creating a recipe for C code, where > >>> the project already has a custom Makefile -which of course must be > >>> used for the build. > >>> From what I recall, the recipe doesn't have to do anything special; > >>> bitbake will pick up the Makefile and do the 'make'... > >>> > >>> However, when experimenting with a v simple 'hello, world' C program > >>> and Makefile, I find that am unable to get a 'debug build' > >>> helloworld_dbg binary executable - it simply seems to use the default > >>> $(CFLAGS) value and I can't seem to influence it, via the recipe or > >>> the Makefile?? > >> > >> Your helloworld_dbg target uses CFLAGS_DBG but I don’t see that defined > >> anywhere. > > Hi Ross, thanks. Yes, sorry, another mistake on my part: I tried > > defining CFLAGS_DBG in the recipe and access it in the Makefile but > > that too didn;t seem to work... > > Did you export it? Variables in recipes are not exported into the > environment of subshells by default. Ok, great, I now exported it.. And yes, it _did_ become visible in the Makefile. *However*, it didn't make any material difference - both binaries are again about the same size, and both show (via 'file') 'with debug_info, not stripped'. So, my point is, even explicitly passing certain CFLAGS_FOO to the custom Makefile via the recipe doesn't make any real difference? That's not great, right... What if one must pass some required flag? Typically, and correct me if i'm wrong, the project Makefile will specify it but bitbake doesn't seem to want to obey the Makefile - it wants to overrule it regardless?? Not great, IMHO.. that is, if I'm understanding this correctly.
> > >> If helloworld_dbg should be unstripped, then the idiom is to _always_ > >> build unstripped binaries (which is why CFLAGS has -g in) and at packaging > >> time bitbake will extract the debug symbols and put them into the -dbg > >> package. Fantastic, it really helps to know this... thanks. > > Ah, so I gather, as you've said, that bitbake will not strip the > > binary and will provide the debug symbols in -dbg package. > > > > So my question really is: the deployed 'production' binary should be > > stripped and optimized, thus should not be compiled with -g and -O0 > > right? > > But the generated helloworld binary shows like this: > > $ file > > .../tmp-glibc/work/cortexa72-kaiwanTECH-linux/hellomake/1.0/helloworld > > .../tmp-glibc/work/cortexa72-kaiwanTECH-linux/hellomake/1.0/helloworld: > > ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically > > linked, interpreter /usr/lib/ld-linux-aarch64.so.1, > > BuildID[sha1]=ae3... for GNU/Linux 5.15.0, with debug_info, not > > stripped > > > > The last part clearly says 'with debug_info, not stripped'; this, IMO, > > conflicts with what we want for production... That's the thing I am > > not getting. > > The idiom is that binaries are build with -g -O2 by default. The debug > symbols are then moved into the -dbg package. So if you just install > helloworld you have a stripped binary, but installing helloworld-dbg brings > in the debug symbols. > > If you want to go a step further because the optimiser is causing sufficient > problems in debugging you can simply set DEBUG_BUILD=“1” in the recipe and > that will swith -O2 to -Og. You can do this with a bbappend or override in > your local.conf, or if you’re really keen a sub-distro that is a rebuild of > your entire system with DEBUG_BUILD enabled globally. Very interesting, thank you.. - Kaiwan. > > Ross
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#63330): https://lists.yoctoproject.org/g/yocto/message/63330 Mute This Topic: https://lists.yoctoproject.org/mt/106629727/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
