Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #81530 > unrolled thread

Ability to further support 32bit architectures

Started byBastian Blank <waldi@debian.org>
First post2024-01-11 10:50 +0100
Last post2024-01-13 18:00 +0100
Articles 1 on this page of 21 — 9 participants

Back to article view | Back to linux.debian.kernel


Contents

  Ability to further support 32bit architectures Bastian Blank <waldi@debian.org> - 2024-01-11 10:50 +0100
    Re: Ability to further support 32bit architectures Dimitri John Ledkov <dimitri.ledkov@canonical.com> - 2024-01-11 10:50 +0100
      Re: Ability to further support 32bit architectures Bastian Blank <waldi@debian.org> - 2024-01-11 11:50 +0100
        Re: Ability to further support 32bit architectures Adrian Bunk <bunk@debian.org> - 2024-01-11 12:50 +0100
          Re: Ability to further support 32bit architectures Aurelien Jarno <aurel32@debian.org> - 2024-01-11 18:40 +0100
            Re: Ability to further support 32bit architectures Aurelien Jarno <aurel32@debian.org> - 2024-01-13 19:50 +0100
        Re: Ability to further support 32bit architectures Jeffrey Walton <noloader@gmail.com> - 2024-01-11 17:10 +0100
          Re: Ability to further support 32bit architectures YunQiang Su <wzssyqa@gmail.com> - 2024-01-12 17:20 +0100
            Re: Ability to further support 32bit architectures Alan Corey <alan01346@gmail.com> - 2024-01-12 19:30 +0100
              Re: Ability to further support 32bit architectures rhys <rhys@neoquasar.org> - 2024-01-13 04:50 +0100
                Re: Ability to further support 32bit architectures YunQiang Su <wzssyqa@gmail.com> - 2024-01-13 04:50 +0100
                  Re: Ability to further support 32bit architectures rhys <rhys@neoquasar.org> - 2024-01-13 14:20 +0100
                    Re: Ability to further support 32bit architectures Rene Engelhard <rene@debian.org> - 2024-01-13 17:00 +0100
                      Re: Offer to make a native 32-bit system avaiable rhys <rhys@neoquasar.org> - 2024-01-13 20:20 +0100
                        Re: Offer to make a native 32-bit system avaiable Dimitri John Ledkov <dimitri.ledkov@canonical.com> - 2024-01-13 21:10 +0100
                Re: Ability to further support 32bit architectures rhys <rhys@neoquasar.org> - 2024-01-13 14:30 +0100
      Re: Ability to further support 32bit architectures Bastian Blank <waldi@debian.org> - 2024-01-12 23:40 +0100
        Re: Ability to further support 32bit architectures Dimitri John Ledkov <dimitri.ledkov@canonical.com> - 2024-01-13 17:40 +0100
          Re: Ability to further support 32bit architectures Bastian Blank <waldi@debian.org> - 2024-01-13 18:00 +0100
    Re: Ability to further support 32bit architectures Bastian Blank <waldi@debian.org> - 2024-01-11 11:50 +0100
    gcc displaying bullshit allocation numbers? (was: Re: Ability to  further support 32bit architectures) Bastian Blank <waldi@debian.org> - 2024-01-13 18:00 +0100

Page 2 of 2 — ← Prev page 1 [2]


#81561 — gcc displaying bullshit allocation numbers? (was: Re: Ability to further support 32bit architectures)

FromBastian Blank <waldi@debian.org>
Date2024-01-13 18:00 +0100
Subjectgcc displaying bullshit allocation numbers? (was: Re: Ability to further support 32bit architectures)
Message-ID<HVPwt-2QmS-11@gated-at.bofh.it>
In reply to#81530
Hi

On Thu, Jan 11, 2024 at 10:25:39AM +0100, Bastian Blank wrote:
> Linux 6.7 fails to build on at least i386 and armhf.  Even it now
> manages to make the compiler fail to allocate memory:
> | cc1: out of memory allocating 135266296 bytes after a total of 235675648 bytes

I just tried to find out what this numbers actually mean.

The first on is the allocation amount, so correct.  The printf spec is
however wrong, as the variable is a size_t (%zu) and not unsigned long
(%lu).

The second one is the return value of "sbrk(0) - $saved sbrk value".

https://github.com/gcc-mirror/gcc/blob/master/libiberty/xmalloc.c#L125-L132

The glibc malloc(3), which seems to be used in the background, uses both
brk(2) and malloc(2), so you can't really see how much you have ever
allocated using this technique.

Am I right in this?

Bastian

-- 
	"Life and death are seldom logical."
	"But attaining a desired goal always is."
		-- McCoy and Spock, "The Galileo Seven", stardate 2821.7

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.kernel


csiph-web