[Buildroot] __mcount on ARC

[Buildroot] __mcount on ARC

[Zoltan Gyarmati]

Dear All,

I'm investigating this [1] autobuild error, where the gpsd build fails
while profiling is enabled, due to undefined reference to `__mcount', on
ARC arch.

Ironically enough due to a bug in the gpsd build config the -pg flag is
not passed to the linker only to the compiler, but after patching that
one, the build issue remains.
According to this thread [2] this happened earlier with ARC but other
package, so is there anything particular about ARC regarding to
profiling? Should we just disable the gpsd profiling option on ARC?



[1]
http://autobuild.buildroot.net/results/88870f5bf4aff557d8eac4e1cc5d3e397e607af0/

[2]
http://buildroot-busybox.2317881.n4.nabble.com/autobuild-buildroot-net-Build-results-for-2017-11-19-td180416.html


Thanks,

-- 
Zoltan Gyarmati
https://zgyarmati.de


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180218/d3452e7c/attachment.asc>

[Buildroot] __mcount on ARC

[Thomas Petazzoni]

Hello,

+Alexey in Cc.

On Sun, 18 Feb 2018 19:45:08 +0100, Zoltan Gyarmati wrote:

> I'm investigating this [1] autobuild error, where the gpsd build fails
> while profiling is enabled, due to undefined reference to `__mcount', on
> ARC arch.
> 
> Ironically enough due to a bug in the gpsd build config the -pg flag is
> not passed to the linker only to the compiler, but after patching that
> one, the build issue remains.
> According to this thread [2] this happened earlier with ARC but other
> package, so is there anything particular about ARC regarding to
> profiling? Should we just disable the gpsd profiling option on ARC?
> 
> [1]
> http://autobuild.buildroot.net/results/88870f5bf4aff557d8eac4e1cc5d3e397e607af0/
> 
> [2]
> http://buildroot-busybox.2317881.n4.nabble.com/autobuild-buildroot-net-Build-results-for-2017-11-19-td180416.html

Alexey, could you comment on this ? I vaguely remember that profiling
was not supported on ARC at some point, but I have no idea if this is
still the case or not.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[Buildroot] __mcount on ARC

[Alexey Brodkin]

Hi Zoltan,

On Mon, 2018-02-19 at 09:09 +0100, Thomas Petazzoni wrote:
> Hello,
> 
> +Alexey in Cc.
> 
> On Sun, 18 Feb 2018 19:45:08 +0100, Zoltan Gyarmati wrote:
> 
> > I'm investigating this [1] autobuild error, where the gpsd build fails
> > while profiling is enabled, due to undefined reference to `__mcount', on
> > ARC arch.

Thanks for doing this!

> > Ironically enough due to a bug in the gpsd build config the -pg flag is
> > not passed to the linker only to the compiler, but after patching that
> > one, the build issue remains.
> > According to this thread [2] this happened earlier with ARC but other
> > package, so is there anything particular about ARC regarding to
> > profiling? Should we just disable the gpsd profiling option on ARC?
> > 
> > [1]
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_88870f5bf4aff557d8eac4e1cc5d3e397e607af0_&d=DwICAg&c=DPL6_X_6J
> > kXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=qUcbt2aQC5rv6A60vraf7le_bHJUKsNqmF82o_vwG88&s=Ex2r0cYgj4xqNS_I3TFKJaGy4ZSEyhGl1WyyW1
> > 880sY&e=
> > 
> > [2]
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__buildroot-2Dbusybox.2317881.n4.nabble.com_autobuild-2Dbuildroot-2Dnet-2DBuild-2Dresults-2Dfor-
> > 2D2017-2D11-2D19-
> > 2Dtd180416.html&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=qUcbt2aQC5rv6A60vraf7le_bHJUKsNqmF82o_vwG88&s=Ig
> > Fx-7wIxdakr0F3vfv1Nlf6kH6Z62gCs0QqtOh0TGI&e=

If you're talking about
http://autobuild.buildroot.net/results/69032f10edcfd65fd81d62a6854a4c06fa204d76/
then it's not the same, there uClibc was used which is known to be lacking
gprof support but in case of gpsd we deal with glibc so read-on...

> Alexey, could you comment on this ? I vaguely remember that profiling
> was not supported on ARC at some point, but I have no idea if this is
> still the case or not.

Looks like ARC port of glibc only defines "_mcount" but not "__mcount", see
------------------------------------->8---------------------------------
arc-linux-readelf -s libc.so.6 | grep mcount
   124: 000b397c     4 FUNC    GLOBAL DEFAULT   11 _mcount@@GLIBC_2.26
   423: 000df95c    44 FUNC    GLOBAL DEFAULT   11 _dl_mcount_wrapper_check@@GLIBC_2.26
  1584: 000df944    22 FUNC    GLOBAL DEFAULT   11 _dl_mcount_wrapper@@GLIBC_2.26
------------------------------------->8---------------------------------

and https://github.com/foss-for-synopsys-dwc-arc-processors/glibc/blob/vineet-glibc-master/sysdeps/arc/machine-gmon.h#L26

I'm an expert in neither glibc nor gprof so not sure what is a difference between
_mcount vs __mcount but for AArch64 thay set "strong_alias (__mcount, _mcount)" here:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/aarch64/mcount.c#l32

So maybe we need to do the same for ARC.

Adding Vineet's who's doing ARC port of glibc to maybe add this missing bit :)

-Alexey

[Buildroot] __mcount on ARC

[Zoltan Gyarmati]

Dear All

On 02/19/2018 09:58 AM, Alexey Brodkin wrote:
> Hi Zoltan,
>
> On Mon, 2018-02-19 at 09:09 +0100, Thomas Petazzoni wrote:
>> Hello,
>>
>> +Alexey in Cc.
>>
>> On Sun, 18 Feb 2018 19:45:08 +0100, Zoltan Gyarmati wrote:
>>
>>> I'm investigating this [1] autobuild error, where the gpsd build fails
>>> while profiling is enabled, due to undefined reference to `__mcount', on
>>> ARC arch.
> Thanks for doing this!
>
>>> Ironically enough due to a bug in the gpsd build config the -pg flag is
>>> not passed to the linker only to the compiler, but after patching that
>>> one, the build issue remains.
>>> According to this thread [2] this happened earlier with ARC but other
>>> package, so is there anything particular about ARC regarding to
>>> profiling? Should we just disable the gpsd profiling option on ARC?
>>>
>>> [1]
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_88870f5bf4aff557d8eac4e1cc5d3e397e607af0_&d=DwICAg&c=DPL6_X_6J
>>> kXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=qUcbt2aQC5rv6A60vraf7le_bHJUKsNqmF82o_vwG88&s=Ex2r0cYgj4xqNS_I3TFKJaGy4ZSEyhGl1WyyW1
>>> 880sY&e=
>>>
>>> [2]
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__buildroot-2Dbusybox.2317881.n4.nabble.com_autobuild-2Dbuildroot-2Dnet-2DBuild-2Dresults-2Dfor-
>>> 2D2017-2D11-2D19-
>>> 2Dtd180416.html&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=qUcbt2aQC5rv6A60vraf7le_bHJUKsNqmF82o_vwG88&s=Ig
>>> Fx-7wIxdakr0F3vfv1Nlf6kH6Z62gCs0QqtOh0TGI&e=
> If you're talking about
> http://autobuild.buildroot.net/results/69032f10edcfd65fd81d62a6854a4c06fa204d76/
> then it's not the same, there uClibc was used which is known to be lacking
> gprof support but in case of gpsd we deal with glibc so read-on...
>
>> Alexey, could you comment on this ? I vaguely remember that profiling
>> was not supported on ARC at some point, but I have no idea if this is
>> still the case or not.
> Looks like ARC port of glibc only defines "_mcount" but not "__mcount", see
> ------------------------------------->8---------------------------------
> arc-linux-readelf -s libc.so.6 | grep mcount
>    124: 000b397c     4 FUNC    GLOBAL DEFAULT   11 _mcount@@GLIBC_2.26
>    423: 000df95c    44 FUNC    GLOBAL DEFAULT   11 _dl_mcount_wrapper_check@@GLIBC_2.26
>   1584: 000df944    22 FUNC    GLOBAL DEFAULT   11 _dl_mcount_wrapper@@GLIBC_2.26
> ------------------------------------->8---------------------------------
>
> and https://github.com/foss-for-synopsys-dwc-arc-processors/glibc/blob/vineet-glibc-master/sysdeps/arc/machine-gmon.h#L26
>
> I'm an expert in neither glibc nor gprof so not sure what is a difference between
> _mcount vs __mcount but for AArch64 thay set "strong_alias (__mcount, _mcount)" here:
> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/aarch64/mcount.c#l32
>
> So maybe we need to do the same for ARC.
>
> Adding Vineet's who's doing ARC port of glibc to maybe add this missing bit :)
>
> -Alexey

Thanks for the background info!
According to the gprof documentation [1]:

"which causes every function to call |mcount| (or |_mcount|, or
|__mcount|, depending on the OS and compiler) as one of its first
operations."

?And a couldn't find any note about difference between the 3 so it seems
we are safe to assume that these are the same.
Is there any intention to patch the ARC glibc in Buildroot with the
mentioned strong_alias (or at later point even the upstream source tree?)
Any opinions?


[1] https://sourceware.org/binutils/docs/gprof/Implementation.html


Zoltan Gyarmati
https://zgyarmati.de

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180219/b4a958ab/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180219/b4a958ab/attachment.asc>

[Buildroot] __mcount on ARC

[Alexey Brodkin]

Hi Zoltan,

On Mon, 2018-02-19 at 21:02 +0100, Zoltan Gyarmati wrote:
> Dear All
> On 02/19/2018 09:58 AM, Alexey Brodkin wrote:
> > Hi Zoltan,
> > 
> > On Mon, 2018-02-19 at 09:09 +0100, Thomas Petazzoni wrote:
> > > Hello,

[snip]
 
> Thanks for the background info!
> According to the gprof documentation [1]:
> 
> "which causes every function to call mcount (or _mcount, or __mcount, depending on the OS and compiler) as one of its first operations."
> 
>  And a couldn't find any note about difference between the 3 so it seems we are safe to assume that these are the same. 
> Is there any intention to patch the ARC glibc in Buildroot with the mentioned strong_alias (or at later point even the upstream source tree?)
> Any opinions?
> 
> 
> [1] https://sourceware.org/binutils/docs/gprof/Implementation.html

Keeping in mind your input I really think it worth addressing in glibc for ARC.
And given our port was not yet upstreamed maybe we may squeeze that approach with
an alias as on AArch64 into the next respin of Vineet's patches and we'll
just get new set of patches on top of the most recent glibc in Buildroot.

Or as a short-term solution just to get rid of that build failure right before
Buildroot release we may just hand-copy "strong_alias (__mcount, _mcount);" in
sysdeps/arc/machine-gmon.h.

Which option do you prefer?

-Alexey

[Buildroot] __mcount on ARC

[Zoltan Gyarmati]

Dear Alexey&All,

On 02/20/2018 04:46 PM, Alexey Brodkin wrote:
> Hi Zoltan,
>
> On Mon, 2018-02-19 at 21:02 +0100, Zoltan Gyarmati wrote:
>> Dear All
>> On 02/19/2018 09:58 AM, Alexey Brodkin wrote:
>>> Hi Zoltan,
>>>
>>> On Mon, 2018-02-19 at 09:09 +0100, Thomas Petazzoni wrote:
>>>> Hello,
> [snip]
>  
>> Thanks for the background info!
>> According to the gprof documentation [1]:
>>
>> "which causes every function to call mcount (or _mcount, or __mcount, depending on the OS and compiler) as one of its first operations."
>>
>>  And a couldn't find any note about difference between the 3 so it seems we are safe to assume that these are the same. 
>> Is there any intention to patch the ARC glibc in Buildroot with the mentioned strong_alias (or at later point even the upstream source tree?)
>> Any opinions?
>>
>>
>> [1] https://sourceware.org/binutils/docs/gprof/Implementation.html
> Keeping in mind your input I really think it worth addressing in glibc for ARC.
> And given our port was not yet upstreamed maybe we may squeeze that approach with
> an alias as on AArch64 into the next respin of Vineet's patches and we'll
> just get new set of patches on top of the most recent glibc in Buildroot.
>
> Or as a short-term solution just to get rid of that build failure right before
> Buildroot release we may just hand-copy "strong_alias (__mcount, _mcount);" in
> sysdeps/arc/machine-gmon.h.
>
> Which option do you prefer?
>
> -Alexey
I think for the upcoming BR release I can just disable the GPSD
profiling option on ARC without touching glibc, and then re-enable it
once ARC glibc is patched and released.
Given that the issue is rather a corner case (i think it's rare that
someone wants to do profiling of gpsd on the target platform anyway, we
just hit it via a random config during autobuild), i think this is the
easiest and least risky solution.
I'm going to send in a BR patch in this spirit.
@Thomas, what do you think?

Regards,

Zoltan Gyarmati
https://zgyarmati.de


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180220/bcbc4d34/attachment.asc>

[Buildroot] __mcount on ARC

[Vineet Gupta]

On 02/19/2018 12:58 AM, Alexey Brodkin wrote:
>
> Looks like ARC port of glibc only defines "_mcount" but not "__mcount", see

It used to be so before glibc commit 46e2c0e216ba ARC: Fix -pg build error which 
has been in my
glibc branch #vineet-glibc-master for quite some time and hopefully is the one 
buildroot is picking up.

The driving force here is gcc which defines what mc* call is generated, and that 
for ARC is __mcount

> ------------------------------------->8---------------------------------
> arc-linux-readelf -s libc.so.6 | grep mcount
>     124: 000b397c     4 FUNC    GLOBAL DEFAULT   11 _mcount@@GLIBC_2.26
>     423: 000df95c    44 FUNC    GLOBAL DEFAULT   11 _dl_mcount_wrapper_check@@GLIBC_2.26
>    1584: 000df944    22 FUNC    GLOBAL DEFAULT   11 _dl_mcount_wrapper@@GLIBC_2.26

On my end, I see

arc-linux-nm ./build/glibc-vineet-glibc-master/build/linkobj/libc.so | grep mcount
00070930 T __mcount

> ------------------------------------->8---------------------------------
>
> and https://github.com/foss-for-synopsys-dwc-arc-processors/glibc/blob/vineet-glibc-master/sysdeps/arc/machine-gmon.h#L26

Look carefully, this actually defines __mcount not _mcount

>
> I'm an expert in neither glibc nor gprof so not sure what is a difference between
> _mcount vs __mcount but for AArch64 thay set "strong_alias (__mcount, _mcount)" here:
> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/aarch64/mcount.c#l32
>
> So maybe we need to do the same for ARC.

No, we don't have to? - don't try to apply bandaid without first checking if it is 
really needed.

-Vineet

[Buildroot] __mcount on ARC

[Alexey Brodkin]

Hi Vineet, Zoltan,

On Tue, 2018-02-20 at 12:53 -0800, Vineet Gupta wrote:
> On 02/19/2018 12:58 AM, Alexey Brodkin wrote:
> > 
> > Looks like ARC port of glibc only defines "_mcount" but not "__mcount", see
> 
> It used to be so before glibc commit 46e2c0e216ba ARC: Fix -pg build error which 
> has been in my
> glibc branch #vineet-glibc-master for quite some time and hopefully is the one 
> buildroot is picking up.

Nope we still refer to "arc-2017.09-release". That will be kept for upcoming BR release
which is happening this month and then we'll switch to newer tag like the most recent
arc-2018.03-eng00x.

> The driving force here is gcc which defines what mc* call is generated, and that 
> for ARC is __mcount
> 
> > ------------------------------------->8---------------------------------
> > arc-linux-readelf -s libc.so.6 | grep mcount
> >     124: 000b397c     4 FUNC    GLOBAL DEFAULT   11 _mcount@@GLIBC_2.26
> >     423: 000df95c    44 FUNC    GLOBAL DEFAULT   11 _dl_mcount_wrapper_check@@GLIBC_2.26
> >    1584: 000df944    22 FUNC    GLOBAL DEFAULT   11 _dl_mcount_wrapper@@GLIBC_2.26
> 
> On my end, I see
> 
> arc-linux-nm ./build/glibc-vineet-glibc-master/build/linkobj/libc.so | grep mcount
> 00070930 T __mcount
> 
> > ------------------------------------->8---------------------------------
> > 
> > and https://github.com/foss-for-synopsys-dwc-arc-processors/glibc/blob/vineet-glibc-master/sysdeps/arc/machine-gmon.h#L26
> 
> Look carefully, this actually defines __mcount not _mcount
> 
> > 
> > I'm an expert in neither glibc nor gprof so not sure what is a difference between
> > _mcount vs __mcount but for AArch64 thay set "strong_alias (__mcount, _mcount)" here:
> > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/aarch64/mcount.c#l32
> > 
> > So maybe we need to do the same for ARC.
> 
> No, we don't have to  - don't try to apply bandaid without first checking if it is 
> really needed.

Thanks for all that technical background.

So Zoltan, please go ahead and disable profiling of GPSD for ARC but please
add a comment like "# Needs glibc for ARC to arc-2018.03-eng007+".

-Alexey