Bazel and map files?

[Charles Nicholson]

I'm building an arm-gcc toolchain and trying to figure out how to get Bazel to generate map files that end up in bazel-bin next to the output elf and objdump'd binary.

I couldn't find an obvious way to do this, and Googling turns up lots of references to map files in other languages like Swift, and associative array data structures that Bazel uses in its implementation :)

When I invoke gcc as a linker from the command line with "-Wl,-Map=hello.map", I get my "hello.map" file as expected.

When I add a similar line to my CROSSTOOL file via 

linker_flag: "-Wl,-Map=hello.map"

I get no map file anywhere under my workspace root, including the bazel-* symlinks that live at my workspace root.

I see with the -s flag that bazel is adding my flag to the gcc link line, and my elf links without error, but I can't find a map file anywhere.

I also don't see my map file anywhere under my Bazel cache. The following command returns no results. (If I change *.map to *.o, I find my object files):

find ~/.cache/bazel -type f -name *.map

This behavior makes me guess that Bazel is building my project in a secret hermetic location, and only copying out the files it /knows/ are part of the dependency graph to the cache, and that my map file isn't getting pulled along for the ride.

Even if I /could/ find my hard-coded map file, CROSSTOOL doesn't look parameterizable. I don't see things like ${EXECUTABLE_OUTPUT_PREFIX} that I'd be able to drop into a linker_flag line. That seems like a requirement for making binary apps that aren't named "hello" :)

So, questions:

1. Does Bazel know anything about generating map files?

2. Are CROSSTOOL flags parameterizable with targets somehow?

Does anyone have any ideas here? I'm loath to dive into the source before asking the experts.

Best,

Charles

[Austin Schuh]

On Sat, Jul 22, 2017 at 2:16 PM 'Charles Nicholson' via bazel-discuss <bazel-...@googlegroups.com> wrote:

This behavior makes me guess that Bazel is building my project in a secret hermetic location, and only copying out the files it /knows/ are part of the dependency graph to the cache, and that my map file isn't getting pulled along for the ride.

That's exactly what is happening.  (You can turn on sandbox debugging and go look in the sandbox folder that's normally removed afterwords to see it)

When we needed a map file, we had already written our own C++ rules (so we could build a .deb with code for multiple architectures).  I haven't had to solve this for the builtin C++ rules.

Austin

[Marcel Hlopko]

Hi Charles,

so bazel C++ rules don't know about map files, so bazel doesn't copy them out of the sandbox. We have 2 options to move forward here: a) teach bazel about map files (we have hardcoded support for .d files for example, but only because bazel actually reads those files ) , or b) allow crosstool to specify arbitrary additional outputs (we had such feature request already).

+Lukács T. Berki +Manuel Klimek Thoughts? :) I cannot seem to find the discussion about crosstool additional inputs, can you pls guide me who needed that?

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CABsbf%3DEc7QAb67Z2HiJs0AxsVLQE0a0vm75tu6zEy9vXRxqVQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

-- 

Marcel Hlopko | Software Engineer | hlo...@google.com | 

Google Germany GmbH | Erika-Mann-Str. 33  | 80636 München | Germany | Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle | Registergericht und -nummer: Hamburg, HRB 86891

[Charles Nicholson]

Thanks for the response.

A colleague of mine suggested a custom rule that always passes "-Wl,-Wmap=" + myelf.map as a link flag and then "myelf.map" as an additional output. That would be a good place to objcopy out a binary from the elf anyway, so it seems reasonable?

I haven't tried it yet, but it means that there would be 3 outputs from this rule: the elf, the bin, the map.

Any red flags around that approach?

Charles

On Wed, Jul 26, 2017 at 3:51 AM, Marcel Hlopko <hlo...@google.com> wrote:

Hi Charles,

so bazel C++ rules don't know about map files, so bazel doesn't copy them out of the sandbox. We have 2 options to move forward here: a) teach bazel about map files (we have hardcoded support for .d files for example, but only because bazel actually reads those files ) , or b) allow crosstool to specify arbitrary additional outputs (we had such feature request already).

+Lukács T. Berki +Manuel Klimek Thoughts? :) I cannot seem to find the discussion about crosstool additional inputs, can you pls guide me who needed that?

On Sun, Jul 23, 2017 at 8:15 AM Austin Schuh <austin...@gmail.com> wrote:

On Sat, Jul 22, 2017 at 2:16 PM 'Charles Nicholson' via bazel-discuss <bazel-discuss@googlegroups.com> wrote:

This behavior makes me guess that Bazel is building my project in a secret hermetic location, and only copying out the files it /knows/ are part of the dependency graph to the cache, and that my map file isn't getting pulled along for the ride.

That's exactly what is happening.  (You can turn on sandbox debugging and go look in the sandbox folder that's normally removed afterwords to see it)

When we needed a map file, we had already written our own C++ rules (so we could build a .deb with code for multiple architectures).  I haven't had to solve this for the builtin C++ rules.

Austin

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discuss+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CABsbf%3DEc7QAb67Z2HiJs0AxsVLQE0a0vm75tu6zEy9vXRxqVQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Lukács T. Berki]

You can't faithfully reproduce the inputs and the command line of an internal link action from Skylark (yet). You could maybe hack something together with extra actions, but it wouldn't be very pleasant to use.

On 26 July 2017 at 19:46, Charles Nicholson <nicho...@google.com> wrote:

Thanks for the response.

A colleague of mine suggested a custom rule that always passes "-Wl,-Wmap=" + myelf.map as a link flag and then "myelf.map" as an additional output. That would be a good place to objcopy out a binary from the elf anyway, so it seems reasonable?

I haven't tried it yet, but it means that there would be 3 outputs from this rule: the elf, the bin, the map.

Any red flags around that approach?

Charles

On Wed, Jul 26, 2017 at 3:51 AM, Marcel Hlopko <hlo...@google.com> wrote:

Hi Charles,

so bazel C++ rules don't know about map files, so bazel doesn't copy them out of the sandbox. We have 2 options to move forward here: a) teach bazel about map files (we have hardcoded support for .d files for example, but only because bazel actually reads those files ) , or b) allow crosstool to specify arbitrary additional outputs (we had such feature request already).

+Lukács T. Berki +Manuel Klimek Thoughts? :) I cannot seem to find the discussion about crosstool additional inputs, can you pls guide me who needed that?

On Sun, Jul 23, 2017 at 8:15 AM Austin Schuh <austin...@gmail.com> wrote:

On Sat, Jul 22, 2017 at 2:16 PM 'Charles Nicholson' via bazel-discuss <bazel-...@googlegroups.com> wrote:

This behavior makes me guess that Bazel is building my project in a secret hermetic location, and only copying out the files it /knows/ are part of the dependency graph to the cache, and that my map file isn't getting pulled along for the ride.

That's exactly what is happening.  (You can turn on sandbox debugging and go look in the sandbox folder that's normally removed afterwords to see it)

When we needed a map file, we had already written our own C++ rules (so we could build a .deb with code for multiple architectures).  I haven't had to solve this for the builtin C++ rules.

Austin

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CABsbf%3DEc7QAb67Z2HiJs0AxsVLQE0a0vm75tu6zEy9vXRxqVQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

-- 

Marcel Hlopko | Software Engineer | hlo...@google.com | 

Google Germany GmbH | Erika-Mann-Str. 33  | 80636 München | Germany | Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle | Registergericht und -nummer: Hamburg, HRB 86891

--

Lukács T. Berki | Software Engineer | lbe...@google.com | 

[Charles Nicholson]

Thanks for the response.

I was wondering if it would be possible to write a custom rule that sets up args and invokes cc_binary. Is that a reasonable thing to try?

[Lukács T. Berki]

It wouldn't work with sandboxing because Bazel wouldn't know about the extra .map file output of the link action.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CACfYaaUYxjZB0Vh9d1M_ZLvit%2BxkJRzbdtPyvYxA0avt6gKqww%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

[sang...@google.com]

Any update on this, does Bazel support map files now?

[Christopher Moynihan]

You can generate a map file during the build with a genrule and include that in a macro that also wraps your cc_binary so you get both with the same target.

Snippet below:

  if generate_map:

    native.genrule(

        name = name + "_map",

        srcs = [elf_rule],

        outs = [name + ".map"],

        tools = ["@gcc//:arm-objdump"],

        cmd = "$(location @gcc//:arm-objdump) -C --all-headers $< > $@",

        tags = tags,

        restricted_to = restricted_to,

        visibility = visibility,

        testonly = testonly)

    filegroup_srcs.append(":%s.map" % (name,))

Where filegroup sources gets turned into a native.filegroup and elf_rule points to your .elf file.

[Dhanalakshmi Durairaj]

Hi,

Greetings to all,

I am working on GHS toolchain.  Ccarm compiler generates “per object debug info file” by providing the flag -G and the extension of the file is .dbo. Debug info file for the archive is .dba. GCC toolchain generates per object debug info file with the extension of .dwo and .dwp (for archive) by providing the flag -gsplit-dwarf. Moreover, I am trying to produce .map file also. How to get these outputs (.dbo,.dba and .map)? Please guide me, is there any way to achieve this without using custom rules?