no code (no .text segment) when forgetting "-C", "link-arg=-Tlink.x" but no warning/error either

[alon]

Hi,

I realize this is not really a bug, I just hoped to get some feedback about where you think this should be reported. The issue is that if you take this template and remove the "-C", "link-arg=-Tlink.x" line from .cargo/config (for instance, by reading this as a reference and copying bits into another project) then everything compiles just fine but the resulting binary is useless.

Here is the output of arm-none-eabi-objdump -h (I called the project devicers):

target/thumbv7em-none-eabihf/debug/devicers2:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .debug_abbrev 00001796  00000000  00000000  00000054  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
  1 .debug_info   000279ed  00000000  00000000  000017ea  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
  2 .debug_aranges 00002460  00000000  00000000  000291d7  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
  3 .debug_str    000427b6  00000000  00000000  0002b637  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
  4 .debug_pubnames 00016c70  00000000  00000000  0006dded  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
  5 .debug_pubtypes 0000114e  00000000  00000000  00084a5d  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
  6 .ARM.attributes 0000003a  00000000  00000000  00085bab  2**0
                  CONTENTS, READONLY
  7 .debug_frame  00007100  00000000  00000000  00085be8  2**2
                  CONTENTS, READONLY, DEBUGGING, OCTETS
  8 .debug_line   00026f57  00000000  00000000  0008cce8  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
  9 .debug_ranges 0001ac38  00000000  00000000  000b3c3f  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 10 .debug_loc    0000006d  00000000  00000000  000ce877  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 11 .comment      00000013  00000000  00000000  000ce8e4  2**0
                  CONTENTS, READONLY

I'm just trying to get some feedback here if this sounds to anybody like an issue worthy of fixing, the issue being that there was no complaint at any point suggesting anything was wrong, only by trying to execute the resulting binary (in my case trying to run it with the cargo-call-stack tool) do you get an error.

Thanks,
Alon

[adamgreig]

I've moved this over to the cortex-m repository as that's where any fix would have to go. Thanks for reporting, this is an easy thing for people to miss especially as the config file is usually hidden.

We could add a check to the cortex-m-rt build script that link-arg=-T is present somewhere in CARGO_ENCODED_RUSTFLAGS, for example:

    let flags = env::var("CARGO_ENCODED_RUSTFLAGS").unwrap_or("".to_string());
    if !flags.contains("link-arg=-T") {
        println!("cargo:warning=cortex-m-rt: No linker script flag found, an empty executable may be produced");
        println!("cargo:warning=cortex-m-rt: See https://github.com/rust-embedded/cortex-m-quickstart/blob/master/.cargo/config.toml#L18 for an example");
    }

which gives:

$ cargo build
warning: cortex-m-rt: No linker script flag found, an empty executable may be produced
warning: cortex-m-rt: See https://github.com/rust-embedded/cortex-m-quickstart/blob/master/.cargo/config.toml#L18 for an example
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s

This doesn't require the linker script be named link.x, because some people may be using a custom linker script with another name, but does check that somehow or other some linker script is set besides the default (which will never produce a useful output). However, I still worry there could be some annoying false positives. We could possibly add a second environment variable that skips the check for those users. It might also be possible to detect this by setting up something in the cortex-m-rt library that will generate a linker error without a good link script, but I'm not sure what that would look like exactly.

Edit: ah, this won't work for users setting the flag from their build.rs. We should probably update quickstart to do that anyway, but we can't do the detection suggested above.

[alon]

Is there a post process hook akin to build.rs? That qould not produce falae positives, i.e. checking for .text directly.

On February 17, 2023 6:41:39 PM GMT+02:00, Adam Greig ***@***.***> wrote: I've moved this over to the `cortex-m` repository as that's where any fix would have to go. Thanks for reporting, this is an easy thing for people to miss especially as the config file is usually hidden. We could add a check to the cortex-m-rt build script that `link-arg=-T` is present somewhere in `CARGO_ENCODED_RUSTFLAGS`, for example: ```rust let flags = env::var("CARGO_ENCODED_RUSTFLAGS").unwrap_or("".to_string()); if !flags.contains("link-arg=-T") { println!("cargo:warning=cortex-m-rt: No linker script flag found, an empty executable may be produced"); println!("cargo:warning=cortex-m-rt: See https://github.com/rust-embedded/cortex-m-quickstart/blob/master/.cargo/config.toml#L18 for an example"); } ``` which gives: ``` $ cargo build warning: cortex-m-rt: No linker script flag found, an empty executable may be produced warning: cortex-m-rt: See https://github.com/rust-embedded/cortex-m-quickstart/blob/master/.cargo/config.toml#L18 for an example Finished dev [unoptimized + debuginfo] target(s) in 0.02s ``` This doesn't require the linker script be named `link.x`, because some people may be using a custom linker script with another name, but does check that somehow or other _some_ linker script is set besides the default (which will never produce a useful output). However, I still worry there could be some annoying false positives. We could possibly add a second environment variable that skips the check for those users. It might also be possible to detect this by setting up something in the cortex-m-rt library that will generate a linker error without a good link script, but I'm not sure what that would look like exactly. -- Reply to this email directly or view it on GitHub: #471 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.