sysdeps/riscv/start.S: rename .Lload_gp to load_gp (bug 24376)
Commit Message
Renaming the symbol keeps the label in the symbol table as a normal local
label, so that `objdump -d' can pick it up as an anchor.
[BZ #24376]
* sysdeps/riscv/start.S (load_gp): Rename from .Lload_gp, all uses
changed.
---
sysdeps/riscv/start.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Comments
* Andreas Schwab:
> Renaming the symbol keeps the label in the symbol table as a normal local
> label, so that `objdump -d' can pick it up as an anchor.
>
> [BZ #24376]
> * sysdeps/riscv/start.S (load_gp): Rename from .Lload_gp, all uses
> changed.
Perhaps use startup_load_gp instead, so that it's less ambiguous in
the debugging information?
On Sep 24 2019, Florian Weimer <fw@deneb.enyo.de> wrote:
> * Andreas Schwab:
>
>> Renaming the symbol keeps the label in the symbol table as a normal local
>> label, so that `objdump -d' can pick it up as an anchor.
>>
>> [BZ #24376]
>> * sysdeps/riscv/start.S (load_gp): Rename from .Lload_gp, all uses
>> changed.
>
> Perhaps use startup_load_gp instead, so that it's less ambiguous in
> the debugging information?
It's a local label, so no conflict possible.
Andreas.
On Tue, Sep 24, 2019 at 9:23 AM Andreas Schwab <schwab@suse.de> wrote:
> On Sep 24 2019, Florian Weimer <fw@deneb.enyo.de> wrote:
> > * Andreas Schwab:
> >> Renaming the symbol keeps the label in the symbol table as a normal local
> >> label, so that `objdump -d' can pick it up as an anchor.
> >
> > Perhaps use startup_load_gp instead, so that it's less ambiguous in
> > the debugging information?
>
> It's a local label, so no conflict possible.
That's not what he was saying.
zw
On Sep 24 2019, Zack Weinberg <zackw@panix.com> wrote:
> On Tue, Sep 24, 2019 at 9:23 AM Andreas Schwab <schwab@suse.de> wrote:
>> On Sep 24 2019, Florian Weimer <fw@deneb.enyo.de> wrote:
>> > * Andreas Schwab:
>> >> Renaming the symbol keeps the label in the symbol table as a normal local
>> >> label, so that `objdump -d' can pick it up as an anchor.
>> >
>> > Perhaps use startup_load_gp instead, so that it's less ambiguous in
>> > the debugging information?
>>
>> It's a local label, so no conflict possible.
>
> That's not what he was saying.
That's because I said that.
Andreas.
On Tue, Sep 24, 2019 at 9:32 AM Andreas Schwab <schwab@suse.de> wrote:
> On Sep 24 2019, Zack Weinberg <zackw@panix.com> wrote:
> > On Tue, Sep 24, 2019 at 9:23 AM Andreas Schwab <schwab@suse.de> wrote:
> >> On Sep 24 2019, Florian Weimer <fw@deneb.enyo.de> wrote:
> >> >
> >> > Perhaps use startup_load_gp instead, so that it's less ambiguous in
> >> > the debugging information?
> >>
> >> It's a local label, so no conflict possible.
> >
> > That's not what he was saying.
>
> That's because I said that.
Yes, the issue is that your response does not address his concern.
zw
@@ -47,7 +47,7 @@ ENTRY (ENTRY_POINT)
.cfi_label to force starting the FDE. */
.cfi_label .Ldummy
cfi_undefined (ra)
- call .Lload_gp
+ call load_gp
mv a5, a0 /* rtld_fini. */
/* main may be in a shared library. */
la a0, main
@@ -68,7 +68,7 @@ END (ENTRY_POINT)
needs to be initialized before calling __libc_start_main in that case.
So we redundantly initialize it at the beginning of _start. */
-.Lload_gp:
+load_gp:
.option push
.option norelax
lla gp, __global_pointer$
@@ -76,7 +76,7 @@ END (ENTRY_POINT)
ret
.section .preinit_array,"aw"
- .dc.a .Lload_gp
+ .dc.a load_gp
/* Define a symbol for the first piece of initialized data. */
.data