Build sonic-broadcom.bin using debug dockers for all stretch based dockers

[renukamanavalan]

- What I did
Enable build of dbg-sonic-broadcom.bin, which uses dbg-dockers in place of regular dockers, for dockers that build debug version. For dockers that do not build debug version, it uses the regular docker.

As of now, all stretch based dockers build a debug version.

The debug version, carries all needed debug symbols and tools (like gdb, gdbserver, ...) required for debugging.

The debug bin is installable like regular bin in a DUT.

Most commonly, as a dev, you may not need the .bin, but just docker--dbg.gz, which you can load & run in your VM, with bash as entrypoint and your core file location mapped. Now you can debug your core in VM.

Have fun debugging!!!
Of course, look at your log file for tidbits, before you go this route. When you write code, make sure to log all your errors, which can save a ton of time, in debugging

- How I did it

- How to verify it

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

[marian-pritsak]

Why is this change related to broadcom?
Why not utilize debug configs and build debug dockers per request?

[marian-pritsak]

Is there any high-level design for this?
It looks like a big and permanent change and needs a review.

[renukamanavalan]

My computer has crashed, hence unable to access. I will get back by tomorrow

Sent from my iPhone On Apr 28, 2019, at 6:02 AM, Marian Pritsak <[email protected]<mailto:[email protected]>> wrote: @marian-pritsak requested changes on this pull request. Is there any high-level design for this? It looks like a big and permanent change and needs a review.

________________________________ In slave.mk<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fsonic-buildimage%2Fpull%2F2833%23discussion_r279193714&data=01%7C01%7CRenuka.Manavalan%40microsoft.com%7C9611695d96e44b2ef4de08d6cbd9b2f5%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=gvUSWWDZ3PYc9tgSOCYdJznI6SjXcUIn9jIInHguiho%3D&reserved=0>:

@@ -664,6 +665,103 @@ $(addprefix $(TARGET_PATH)/, $(SONIC_INSTALLERS)) : $(TARGET_PATH)/% : \

SONIC_TARGET_LIST += $(addprefix $(TARGET_PATH)/, $(SONIC_INSTALLERS)) +# targets for building debug installers with base image +$(addprefix $(TARGET_PATH)/, $(SONIC_DBG_INSTALLERS)) : $(TARGET_PATH)/$(DBG_IMAGE_MARK)-% : \ It looks like a copy of a target above, which makes it hard to maintain and update. What's the difference from the above? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fsonic-buildimage%2Fpull%2F2833%23pullrequestreview-231467380&data=01%7C01%7CRenuka.Manavalan%40microsoft.com%7C9611695d96e44b2ef4de08d6cbd9b2f5%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=QkgClU%2FcPz7qRXNIIkKYeNk0erdhl1FmzhCK6GYuvvg%3D&reserved=0>, or mute the thread<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FALIXUJLAZN7TIRO272F5NFTPSWN4NANCNFSM4HI5LGKQ&data=01%7C01%7CRenuka.Manavalan%40microsoft.com%7C9611695d96e44b2ef4de08d6cbd9b2f5%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=pJAVhZyRiVtNm8vGJRa0dLOgNL%2FI1u2uSX9T3GGi5eA%3D&reserved=0>.

[renukamanavalan]

Hi Marian,

Yes indeed this is one of the final pieces of the work, with debug dockers.

Main Goal:
To transparently build debug docker images for each docker image.

Gain/purpose of the goal:
Today, if you need to a debug session, on a dead core file or live debugging, you need to find DUT running that version, get into docker container, download & install all debug symbols and download/install debug tools like gdb.

If you are looking at core files from two different versions, you need two DUTs (virtual/real)

With this goal:
To analyze a dead core file, you don't need any DUT. From the build server, get debug version of your docker, run the docker in any docker-supported environment (e.g. a VM running linux), load & run the docker with bash as entrypoint and core file mapped.
This saves us a lot of time and reduce our requirements.

To do live debugging, instead of upgrading your docker with debug symbols & tools, get the debug version of the same docker from the build server, load that image and you are set to go.

BTW, this main goal is already accomplished for all stretch based dockers, through following PRs that are committed.

#2753
#2789
#2812

Add-on goal:
Now the debug docker images are available for all stretch based dockers. With goal of moving all dockers to stretch based, soon all docker images will have a debug version available.

So wonder, why not build a debug version of final sonic image (.bin/.swi/...) using debug docker images.

With this, you could have a real/virtual DUT with all docker images enhanced with debug symbols & tools.

This PR is the first step, to build debug version of sonic-broadcom.bin.

[lguohan]

it is better to put dbg as a suffix instead of prefix. sonic-broadom-dbg.bin.

[renukamanavalan]

done

[lguohan]

agree with marian, it is better to have a design doc as this question will be raise every pr. @renukamanavalan , can you prepare a design doc?

[lguohan]

the approach is a little bit complicated than I think. I think you can just define an option ENABLE_DBG_BUILD = y. When it is enabled, then when you build sonic-broadcom.bin, then it is using the debug docker, then you do not need most of the changes in the slave.mk. Since you are not using a new image name.

it is much easier, the only difference between a normal build and a debug build is load different dockers. You will be able to support build debug swi, debug kvm image by default.

[lguohan]

define a ENABLE_DEBUG_BUILD = y option, when option is enabled, build sonic-broadcom.bin using debug docker images. do not change the build target name sonic-broadcom.bin. it is where all complexity coming from in your current pr. user can management to build sonic-broadcom.bin and rename it to sonic-broadcom-dbg.bin.

[renukamanavalan]

retest this please

[lguohan]

revert to use INSTALL_DEBUG_TOOLS option.

[lguohan]

@marian-pritsak, can you review again?