LLD : __start_ and __end_ symbols for orphan sections

lld does not seem to create the __start and __end symbols for orphan sections.

I would like to keep my linker script as generic as possible so how can I tell lld to create these symbols without having to add them in the linker script?

Thanks

A

It works for me.

SECTIONS {
   data : { *(data) }
}

.section data,"aw"
.quad __start_orphan
.quad __stop_orphan

.section orphan,"aw"
.quad __start_data
.quad __stop_data

Can you give an example __start_ or __end_ symbols are not defined for orphan sections?

You are right it creates them but sets the protected flag (STV_PROTECTED) which seems to be the cause of my problem.
How can I tell it to set the flag as STV_DEFAULT?

Thanks
A

    NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

    >lld does not seem to create the __start and __end symbols for orphan sections.
    >I would like to keep my linker script as generic as possible so how can I tell lld to create these symbols without having to add them in the linker script?
    >
    >Thanks
    >A

    It works for me.

    SECTIONS {
       data : { *(data) }
    }

    .section data,"aw"
    .quad __start_orphan
    .quad __stop_orphan

    .section orphan,"aw"
    .quad __start_data
    .quad __stop_data

    Can you give an example __start_ or __end_ symbols are not defined for orphan sections?

Sorry for the cryptic code but I had to modify stuff from original
In the following example see the difference when you comment or uncomment the line in the linker script:
============ test.c ============= :
struct orphan_dummy_anno_s {
void (*func)(void);
};

static void dummy_export_dbg_log_init_f (void) __attribute__ ((unused));
static struct orphan_dummy_anno_s const
  dummy_export_dbg_log_init_linker_set =
  { dummy_export_dbg_log_init_f, };
__asm__ (".globl " "__start_set_orphan_dummy_anno");
__asm__ (".globl " "__stop_set_orphan_dummy_anno");
static void const
  *__set_orphan_dummy_anno_sym_dummy_export_dbg_log_init_linker_set
  __attribute__ ((__section__ ("set_" "orphan_dummy_anno")))
  __attribute__ ((__used__)) = &dummy_export_dbg_log_init_linker_set;
============ linker_script ============= :
SECTIONS {
   data : { *(data) }
# when commented, the __start and __stop symbols will be protected. How can I keep it from setting it as protected?
# set_orphan_dummy_anno : { PROVIDE(__start_set_orphan_dummy_anno = . ); *(set_orphan_dummy_anno) PROVIDE (__stop_set_orphan_dummy_anno = . );}
}
============ howto ============= :
LDFLAGS="-Bshareable -T ./linker_script"
clang -fPIC -c test.c
ld.lld $LDFLAGS test.o -o test.so
objdump -tT test.so

    NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

    You are right it creates them but sets the protected flag (STV_PROTECTED) which seems to be the cause of my problem.
    How can I tell it to set the flag as STV_DEFAULT?

    Thanks
    A

        NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

        >lld does not seem to create the __start and __end symbols for orphan sections.
        >I would like to keep my linker script as generic as possible so how can I tell lld to create these symbols without having to add them in the linker script?
        >
        >Thanks
        >A

        It works for me.

        SECTIONS {
           data : { *(data) }
        }

        .section data,"aw"
        .quad __start_orphan
        .quad __stop_orphan

        .section orphan,"aw"
        .quad __start_data
        .quad __stop_data

        Can you give an example __start_ or __end_ symbols are not defined for orphan sections?

Sorry for the cryptic code but I had to modify stuff from original
In the following example see the difference when you comment or uncomment the line in the linker script:
============ test.c ============= :
struct orphan_dummy_anno_s {
void (*func)(void);
};

static void dummy_export_dbg_log_init_f (void) __attribute__ ((unused));
static struct orphan_dummy_anno_s const
dummy_export_dbg_log_init_linker_set =
{ dummy_export_dbg_log_init_f, };
__asm__ (".globl " "__start_set_orphan_dummy_anno");
__asm__ (".globl " "__stop_set_orphan_dummy_anno");
static void const
*__set_orphan_dummy_anno_sym_dummy_export_dbg_log_init_linker_set
__attribute__ ((__section__ ("set_" "orphan_dummy_anno")))
__attribute__ ((__used__)) = &dummy_export_dbg_log_init_linker_set;
============ linker_script ============= :
SECTIONS {
  data : { *(data) }
# when commented, the __start and __stop symbols will be protected. How can I keep it from setting it as protected?
# set_orphan_dummy_anno : { PROVIDE(__start_set_orphan_dummy_anno = . ); *(set_orphan_dummy_anno) PROVIDE (__stop_set_orphan_dummy_anno = . );}
}
============ howto ============= :
LDFLAGS="-Bshareable -T ./linker_script"
clang -fPIC -c test.c
ld.lld $LDFLAGS test.o -o test.so
objdump -tT test.so

Making __start_* __stop_* STV_PROTECTED is a deliberate choice. See
https://reviews.llvm.org/D44566
Such symbols can still be exported to .dynsym (can be looked up from
another shared object with dlopen) but prevent accidental symbol preemption..

Okay
Thank you

    NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

    >Sorry for the cryptic code but I had to modify stuff from original
    >In the following example see the difference when you comment or uncomment the line in the linker script:
    >============ test.c ============= :
    >struct orphan_dummy_anno_s {
    > void (*func)(void);
    >};
    >
    >static void dummy_export_dbg_log_init_f (void) __attribute__ ((unused));
    >static struct orphan_dummy_anno_s const
    > dummy_export_dbg_log_init_linker_set =
    > { dummy_export_dbg_log_init_f, };
    >__asm__ (".globl " "__start_set_orphan_dummy_anno");
    >__asm__ (".globl " "__stop_set_orphan_dummy_anno");
    >static void const
    > *__set_orphan_dummy_anno_sym_dummy_export_dbg_log_init_linker_set
    > __attribute__ ((__section__ ("set_" "orphan_dummy_anno")))
    > __attribute__ ((__used__)) = &dummy_export_dbg_log_init_linker_set;
    >============ linker_script ============= :
    >SECTIONS {
    > data : { *(data) }
    ># when commented, the __start and __stop symbols will be protected. How can I keep it from setting it as protected?
    ># set_orphan_dummy_anno : { PROVIDE(__start_set_orphan_dummy_anno = . ); *(set_orphan_dummy_anno) PROVIDE (__stop_set_orphan_dummy_anno = . );}
    >}
    >============ howto ============= :
    >LDFLAGS="-Bshareable -T ./linker_script"
    >clang -fPIC -c test.c
    >ld.lld $LDFLAGS test.o -o test.so
    >objdump -tT test.so

    Making __start_* __stop_* STV_PROTECTED is a deliberate choice. See
    https://reviews.llvm.org/D44566
    Such symbols can still be exported to .dynsym (can be looked up from
    another shared object with dlopen) but prevent accidental symbol preemption..

In our case, we’d prefer the opposite that is for __start/__stop symbols to be always hidden (which is something Rafael also pointed out in https://reviews.llvm.org/D44566#1041984), currently this also requires a linker script on our side which is unfortunate. I have created a change https://reviews.llvm.org/D55682 to provide the -z hidden-start-stop-symbol but this was rejected. I’m wondering if it’d make sense to extend that change to instead provide -z start-stop-symbol-visibility= which could be used to override visibility for __start/__stop symbol (i.e. default or hidden) which would match the frontend -fvisibility= flag. Would that be acceptable?

In our case, we'd prefer the opposite that is for __start/__stop symbols to
be always hidden (which is something Rafael also pointed out in
⚙ D44566 [ELF] - Make __start_/__stop_<section_name> symbols STV_PROTECTED), currently this also requires a
linker script on our side which is unfortunate. I have created a change
⚙ D55682 [ELF] Add -z start-stop-visibility= to set __start_/__stop_ symbol visibility to provide the -z hidden-start-stop-symbol
but this was rejected. I'm wondering if it'd make sense to extend that
change to instead provide -z start-stop-symbol-visibility= which could be
used to override visibility for __start/__stop symbol (i.e. default or
hidden) which would match the frontend -fvisibility= flag. Would that be
acceptable?

See pcc and ruiu's objection in the review ⚙ D55682 [ELF] Add -z start-stop-visibility= to set __start_/__stop_ symbol visibility
My feeling is similar: this extension looks of little value to me.

//extern char __start_f __attribute__((visibility("hidden")));
extern char __start_f; // Fuchsia wants to write code like this, but its visibility is set to hidden due to -z hidden-start-stop-symbols

If you want to persist, asking binutils@sourceware.org may help.
If they'd like to accept the extension, I think the option may get a
change passing pcc and ruiu's bar for an extension.