grub-devel.gnu.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).