All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [RFC PATCH 2/3] Files reorganization and include some libgcc fuctions
Date: Sun, 21 Sep 2014 18:07:05 +0200	[thread overview]
Message-ID: <541EF7A9.1020005@gmail.com> (raw)
In-Reply-To: <20140917214336.GA13292@beren.chocolate>

[-- Attachment #1: Type: text/plain, Size: 7887 bytes --]

On 17.09.2014 23:43, Paulo Flabiano Smorigo wrote:
> Colin, I changed the patches following your suggestions and making it
> more likely to the no-libgcc branch from Vladimir. In this branch,
> phcoder added compiler-rt.{c,h,S} with the necessary code in it.
> 
compiler-rt.{c,S} fixes bunch of possible problems when libgcc doesn't
match the intended platform (e.g. because of SSE flags). So I think we
should have whole thing go in.
Biggest problem is the lack of tests for those functions.
> My approach is very minimalist and only for powerpc. I tried to avoid
> change the behavior for other architecture since we are in code freeze.
> 
> In the future we can think in spread this approach for all archs and use
> all implementation that phcoder is doing in the no-libgcc branch.
> 
> Mon, Sep 08, 2014 at 03:16:21AM +0100, Colin Watson wrote:
>> On Thu, Aug 28, 2014 at 04:56:04PM -0300, Paulo Flabiano Smorigo wrote:
>>> diff --git a/grub-core/kern/misc.c b/grub-core/kern/misc.c
>>> index c5c815d..353a207 100644
>>> --- a/grub-core/kern/misc.c
>>> +++ b/grub-core/kern/misc.c
>>> @@ -1342,3 +1342,110 @@ grub_real_boot_time (const char *file,
>>>    grub_error_pop ();
>>>  }
>>>  #endif
>>> +
>>> +#if defined (NO_LIBGCC)
>>
>> Should this perhaps be restricted to __powerpc__ as well?
>> Alternatively, the prototypes in include/grub/compiler.h (or
>> include/grub/misc.h; see below) should be used on other architectures
>> too.  Either way, the declarations and definitions should match.
> 
> Yes, now I only use __powerpc__
> 
>>
>>> diff --git a/include/grub/compiler.h b/include/grub/compiler.h
>>> index c9e1d7a..a9a684c 100644
>>> --- a/include/grub/compiler.h
>>> +++ b/include/grub/compiler.h
>>> @@ -48,4 +48,65 @@
>>>  #  define WARN_UNUSED_RESULT
>>>  #endif
>>>  
>>> +#include "types.h"
>>
>> Shouldn't this be #include <grub/types.h>, assuming that you need this
>> for grub_uint*_t?  Also, includes should generally be grouped at the top
>> of the file.
> 
> All in the compile-rt.c now
> 
>>
>>> +union component64
>>> +{
>>> +  grub_uint64_t full;
>>> +  struct
>>> +  {
>>> +#ifdef GRUB_CPU_WORDS_BIGENDIAN
>>> +    grub_uint32_t high;
>>> +    grub_uint32_t low;
>>> +#else
>>> +    grub_uint32_t low;
>>> +    grub_uint32_t high;
>>> +#endif
>>> +  };
>>> +};
>>
>> This is only used by grub-core/kern/misc.c.  Please move it there rather
>> than putting it somewhere that's included by everything in GRUB.
>>
>>> +#if defined (__powerpc__)
>>
>> Should this be #if defined (__powerpc__) && defined (NO_LIBGCC) or
>> something similar, to match the general way things are set up in
>> configure.ac?  (Also see comment above about declarations matching
>> definitions.)
> 
> Fixed.
> 
>>
>> Relatedly, have you tested this patch set with a native build on a
>> 32-bit BE powerpc system, as opposed to 32-bit BE built on a 64-bit LE
>> system?  This looks like a potential problem there.
>>
> 
> Yes. I tested it in both BE and LE systems. No problem found. I did
> another round of test with this changes and will do some more this week.
> 
>>> +grub_uint64_t EXPORT_FUNC (__lshrdi3) (grub_uint64_t u, int b);
>>> +grub_uint64_t EXPORT_FUNC (__ashrdi3) (grub_uint64_t u, int b);
>>> +grub_uint64_t EXPORT_FUNC (__ashldi3) (grub_uint64_t u, int b);
>>> +int EXPORT_FUNC(__ucmpdi2) (grub_uint64_t a, grub_uint64_t b);
>>> +void EXPORT_FUNC (_restgpr_14_x) (void);
>> [...]
>>
>> These aren't compiler features, so don't belong in
>> include/grub/compiler.h.  Other architectures seem to have this kind of
>> thing in include/grub/misc.h inside a big #ifndef GRUB_UTIL conditional,
>> so please move all this to there.
> 
> Yes, I follow what phcoder did in no-libgcc branch. This lines are in
> the compiler-rt.c file.
> 
>>
>>> diff --git a/include/grub/libgcc.h b/include/grub/libgcc.h
>>> index 8e93b67..5bdb8fb 100644
>>> --- a/include/grub/libgcc.h
>>> +++ b/include/grub/libgcc.h
>>> @@ -16,73 +16,6 @@
>>>   *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
>>>   */
>>>  
>>> -/* We need to include config-util.h.in for HAVE_*.  */
>>> -#ifndef __STDC_VERSION__
>>> -#define __STDC_VERSION__ 0
>>> -#endif
>>> -#include <config-util.h>
>>> -
>>> -/* On x86 these functions aren't really needed. Save some space.  */
>>> -#if !defined (__i386__) && !defined (__x86_64__)
>>> -# ifdef HAVE___ASHLDI3
>>> -void EXPORT_FUNC (__ashldi3) (void);
>>> -# endif
>>> -# ifdef HAVE___ASHRDI3
>>> -void EXPORT_FUNC (__ashrdi3) (void);
>>> -# endif
>>> -# ifdef HAVE___LSHRDI3
>>> -void EXPORT_FUNC (__lshrdi3) (void);
>>> -# endif
>>> -# ifdef HAVE___UCMPDI2
>>> -void EXPORT_FUNC (__ucmpdi2) (void);
>>> -# endif
>>> -# ifdef HAVE___BSWAPSI2
>>> -void EXPORT_FUNC (__bswapsi2) (void);
>>> -# endif
>>> -# ifdef HAVE___BSWAPDI2
>>> -void EXPORT_FUNC (__bswapdi2) (void);
>>> -# endif
>>> -#endif
>>> -
>>> -#ifdef HAVE__RESTGPR_14_X
>>> -void EXPORT_FUNC (_restgpr_14_x) (void);
>>> -void EXPORT_FUNC (_restgpr_15_x) (void);
>>> -void EXPORT_FUNC (_restgpr_16_x) (void);
>>> -void EXPORT_FUNC (_restgpr_17_x) (void);
>>> -void EXPORT_FUNC (_restgpr_18_x) (void);
>>> -void EXPORT_FUNC (_restgpr_19_x) (void);
>>> -void EXPORT_FUNC (_restgpr_20_x) (void);
>>> -void EXPORT_FUNC (_restgpr_21_x) (void);
>>> -void EXPORT_FUNC (_restgpr_22_x) (void);
>>> -void EXPORT_FUNC (_restgpr_23_x) (void);
>>> -void EXPORT_FUNC (_restgpr_24_x) (void);
>>> -void EXPORT_FUNC (_restgpr_25_x) (void);
>>> -void EXPORT_FUNC (_restgpr_26_x) (void);
>>> -void EXPORT_FUNC (_restgpr_27_x) (void);
>>> -void EXPORT_FUNC (_restgpr_28_x) (void);
>>> -void EXPORT_FUNC (_restgpr_29_x) (void);
>>> -void EXPORT_FUNC (_restgpr_30_x) (void);
>>> -void EXPORT_FUNC (_restgpr_31_x) (void);
>>> -void EXPORT_FUNC (_savegpr_14) (void);
>>> -void EXPORT_FUNC (_savegpr_15) (void);
>>> -void EXPORT_FUNC (_savegpr_16) (void);
>>> -void EXPORT_FUNC (_savegpr_17) (void);
>>> -void EXPORT_FUNC (_savegpr_18) (void);
>>> -void EXPORT_FUNC (_savegpr_19) (void);
>>> -void EXPORT_FUNC (_savegpr_20) (void);
>>> -void EXPORT_FUNC (_savegpr_21) (void);
>>> -void EXPORT_FUNC (_savegpr_22) (void);
>>> -void EXPORT_FUNC (_savegpr_23) (void);
>>> -void EXPORT_FUNC (_savegpr_24) (void);
>>> -void EXPORT_FUNC (_savegpr_25) (void);
>>> -void EXPORT_FUNC (_savegpr_26) (void);
>>> -void EXPORT_FUNC (_savegpr_27) (void);
>>> -void EXPORT_FUNC (_savegpr_28) (void);
>>> -void EXPORT_FUNC (_savegpr_29) (void);
>>> -void EXPORT_FUNC (_savegpr_30) (void);
>>> -void EXPORT_FUNC (_savegpr_31) (void);
>>> -#endif
>>> -
>>>  #if defined (__arm__)
>>>  void EXPORT_FUNC (__aeabi_lasr) (void);
>>>  void EXPORT_FUNC (__aeabi_llsl) (void);
>>
>> I don't think you should touch this file at all.  I don't know precisely
>> how it's used, but it only seems to be used to generate symbol lists;
>> furthermore, you're removing some things from it that are not clearly
>> powerpc-specific and either making them powerpc-specific (__ashldi3,
>> __ashrdi3, __lshrdi3, __ucmpdi2) or dropping them altogether
>> (__bswapsi2, __bswapdi2).  This is worrisome and suggests the
>> possibility that this will break other architectures.  Does your patch
>> work if you just leave include/grub/libgcc.h unmodified?
> 
> Please, check this new patchset. libgcc.h is intact.
> 
>>
>> Thanks,
>>
>> -- 
>> Colin Watson                                       [cjwatson@ubuntu.com]
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

  parent reply	other threads:[~2014-09-21 16:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-28 19:56 [RFC PATCH 0/3] grub powerpc64 little-endian enablement Paulo Flabiano Smorigo
2014-08-28 19:56 ` [RFC PATCH 1/3] Add powerpc little-endian (ppc64le) flags Paulo Flabiano Smorigo
2014-09-17 22:04   ` Paulo Flabiano Smorigo
2014-09-19 13:48     ` Colin Watson
2014-09-21 16:05     ` Vladimir 'φ-coder/phcoder' Serbinenko
2014-08-28 19:56 ` [RFC PATCH 2/3] Files reorganization and include some libgcc fuctions Paulo Flabiano Smorigo
2014-09-08  2:16   ` Colin Watson
2014-09-17 21:43     ` Paulo Flabiano Smorigo
2014-09-19 14:03       ` Colin Watson
2014-09-21 16:07       ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2014-08-28 19:56 ` [RFC PATCH 3/3] Suport for bi-endianess in elf file Paulo Flabiano Smorigo
2015-06-16 16:44   ` Andrei Borzenkov
2014-09-21 13:58 ` [RFC PATCH 0/3] grub powerpc64 little-endian enablement Andrei Borzenkov
2014-09-21 14:24   ` Andrei Borzenkov
2014-09-25 22:48     ` Paulo Flabiano Smorigo
2014-09-26 15:52       ` Andrei Borzenkov
2014-09-26 18:18         ` Paulo Flabiano Smorigo
2015-06-15 17:15 ` Andrei Borzenkov
2015-06-16 12:36   ` Paulo Flabiano Smorigo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=541EF7A9.1020005@gmail.com \
    --to=phcoder@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.