Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 08:59
    KrullBorg commented #2397
  • 08:43

    dependabot[bot] on npm_and_yarn

    (compare)

  • 08:43
    dependabot[bot] closed #144
  • 08:43
    dependabot[bot] edited #144
  • 08:43
    dependabot[bot] commented #144
  • 08:43
    dependabot[bot] edited #144
  • 08:42

    eine on master

    bump dependencies (compare)

  • 08:42
    KrullBorg commented #2397
  • 08:30
    carlkl opened #2554
  • 07:19
    Biswa96 commented #8759
  • 06:53
    naveen521kk synchronize #8969
  • 06:44
    naveen521kk synchronize #8969
  • 06:43
    naveen521kk synchronize #8969
  • 06:35
    naveen521kk edited #8969
  • 06:35
    naveen521kk synchronize #8969
  • 06:33
    naveen521kk opened #8969
  • 06:07
    jeremyd2019 commented #8759
  • 05:55
    jeremyd2019 commented #47
  • 05:40
    jeremyd2019 commented #47
  • 04:01
    dependabot[bot] labeled #144
zygon.sisyphus
@zygon.sisyphus:matrix.org
[m]
Jeroen Ooms
@jeroen

@jeroen ucrt still targets win7

Ah okay. I was confused by this: https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-headers-git/PKGBUILD#L43-L46

So CARCH == "x86_64" even for ucrt-x86_64 ?
Biswapriyo Nath
@Biswa96
Jeroen Ooms
@jeroen
thanks!
ofry
@ofry
Hello. Which memory model used in MinGW64 gcc?
dangyajun
@dangyajun
        #include <stdint.h>
typedef uint64_t    uintx_t;

#define UINTX_ZERO(x)        do{ (x) = 0; } while (0)
#define UINTX_STALL(x)        do{ (x) = UINT64_MAX; } while ( 0 ) 
#define UINTX_STI(x, i)        do{ (x) = ((x) | (i)); } while( 0 )
#define UINTX_CLI(x, i)        ((x) &= ~(i))
#define UINTX_MERGE(x, b)    ((x) |= (b))


#define __TBLFN(x)        (x)
static uintx_t    uintx_tbl[64] = {
    __UINTX_SET_U64(__TBLFN)
};

#define UINTX_CHK(x, i)        ((x) & (i))
#define UINTX_POPCNT(x)        _mm_popcnt_u64(x)
struct kbitmap {
    size_t        uxcnt;
    size_t        size;
    uintx_t        bitbuf[];
};

#define KBITMAP_HDRSIZE(size)    (sizeof(struct kbitmap) + kbitmap_xcount(size))

static inline bool kbitmap_init(struct kbitmap* pkb, size_t num_bits){
    assert( NULL != pkb && num_bits > 0 );
    if( NULL == pkb || 0 >= num_bits ){
        return false;
    }
    size_t uxcount = kbitmap_xcount(num_bits);

    for( size_t i = 0; i < uxcount; ++i ){
        UINTX_ZERO( pkb->bitbuf[i] );
    }
    pkb->uxcnt    = uxcount;
    pkb->size    = num_bits;

    return true;
}

static inline void kbitmap_uninit(struct kbitmap* pkb){
    if( NULL != pkb ){
        pkb->uxcnt    = 0;
        pkb->size    = 0;
    }
}

static inline struct kbitmap kbitmap_create(size_t num_bits){
assert( num_bits > 0 );
struct kbitmap
pkb = (struct kbitmap*)malloc(KBITMAP_HDRSIZE(num_bits));
if( NULL == pkb ){
return NULL;
}

if( false == kbitmap_init(pkb, num_bits) ){
    free(pkb);
    return NULL;
}

return pkb;

}

static inline void kbitmap_destory(struct kbitmap* pkb){
assert( NULL != pkb );
if( NULL != pkb ){
kbitmap_uninit(pkb);
free(pkb);
}
}

static inline bool kbitmap_cli(struct kbitmap pkb, size_t bitindex){
assert( NULL != pkb ); /
清空某一位/
if( NULL == pkb || 0 >= bitindex ){
return false;
}
size_t _slot = (bitindex / (sizeof(uintx_t)
CHAR_BIT));
size_t _index = (bitindex % (sizeof(uintx_t) * CHAR_BIT));

printf("slot = [%u], index = [%u]\n", _slot, _index);
UINTX_CLI( pkb->bitbuf[_slot], uintx_tbl[_index]);

return true;

}

static inline bool kbitmap_sti(struct kbitmap pkb, size_t bitindex){
assert( NULL != pkb ); /
设置某一位/
if( NULL == pkb || 0 >= bitindex ){
return false;
}
size_t _slot = (bitindex / (sizeof(uintx_t)
CHAR_BIT));
size_t _index = (bitindex % (sizeof(uintx_t) * CHAR_BIT));

printf("slot = [%u], index = [%u]\n", _slot, _index);
UINTX_STI( pkb->bitbuf[_slot], uintx_tbl[_index]);

return true;

}
static inline bool kbitmap_get(struct kbitmap pkb, size_t bitindex){
assert( NULL != pkb );
if( NULL == pkb || 0 >= bitindex ){
return false;
}
size_t _slot = (bitindex / (sizeof(uintx_t)
CHAR_BIT));
size_t _index = (bitindex % (sizeof(uintx_t) * CHAR_BIT));

printf("slot = [%u], index = [%u]\n", _slot, _index);
if( UINTX_CHK( pkb->bitbuf[_slot], uintx_tbl[_index]) ){
    return true;
}

return false;

}
flexiable array has no error on linux, but on windows' execution is wrong, no error, no output..... test program :

include <kbitmap.h>

int main(){
printf("hello world!\n");
struct kbitmap* pkb = kbitmap_create(1024);

if( false == kbitmap_sti(pkb, 1023) ){
    printf("error: kbitmap_sti 1023\n");
    kbitmap_destory(pkb);
    abort();
}else {
    printf("ok: kbitmap_sti 1023\n");
}
kbitmap_dump(pkb);


if( false == kbitmap_get( pkb, 1023) ){
    printf("error: kbitmap_get 1023\n");
    kbitmap_destory(pkb);
    abort();
}else {
    printf("ok: kbitmap_get 1023\n");
}

if 0

if( true == kbitmap_get( pkb, 1022) ){
    printf("error: kbitmap_get 1022\n");
    kbitmap_destory(pkb);
    abort();
}else {
    printf("ok: kbitmap_get 1022\n");
}

endif

kbitmap_destory(pkb);
return 0;

}

flexiable array has no error on linux, but on windows' execution is wrong, no error, no output.....

define UINTX_SET_U64(FN) \

__FN(1ULL<<0),  __FN(1ULL<<1),  __FN(1ULL<<2),  __FN(1ULL<<3),    \
__FN(1ULL<<4),  __FN(1ULL<<5),  __FN(1ULL<<6),  __FN(1ULL<<7),    \
__FN(1ULL<<8),  __FN(1ULL<<9),  __FN(1ULL<<10),    __FN(1ULL<<11),    \
__FN(1ULL<<12), __FN(1ULL<<13), __FN(1ULL<<14), __FN(1ULL<<15),    \
__FN(1ULL<<16),    __FN(1ULL<<17), __FN(1ULL<<18),    __FN(1ULL<<19),    \
__FN(1ULL<<20),    __FN(1ULL<<21),    __FN(1ULL<<22),    __FN(1ULL<<23),    \
__FN(1ULL<<24),    __FN(1ULL<<25),    __FN(1ULL<<26),    __FN(1ULL<<27),    \
__FN(1ULL<<28),    __FN(1ULL<<29),    __FN(1ULL<<20),    __FN(1ULL<<31),    \
__FN(1ULL<<32),    __FN(1ULL<<33),    __FN(1ULL<<34),    __FN(1ULL<<35),    \
__FN(1ULL<<36),    __FN(1ULL<<37),    __FN(1ULL<<38),    __FN(1ULL<<39),    \
__FN(1ULL<<40),    __FN(1ULL<<41),    __FN(1ULL<<42),    __FN(1ULL<<43),    \
__FN(1ULL<<44),    __FN(1ULL<<45),    __FN(1ULL<<46),    __FN(1ULL<<47),    \
__FN(1ULL<<48),    __FN(1ULL<<49),    __FN(1ULL<<50),    __FN(1ULL<<51),    \
__FN(1ULL<<52),    __FN(1ULL<<53),    __FN(1ULL<<54),    __FN(1ULL<<55),    \
__FN(1ULL<<56),    __FN(1ULL<<57),    __FN(1ULL<<58),    __FN(1ULL<<59),    \
__FN(1ULL<<60),    __FN(1ULL<<61),    __FN(1ULL<<62),    __FN(1ULL<<63)
image.png
image.png
Mateusz Mikuła
@mati865:matrix.org
[m]
@ofry: AFAIK it's medium for x86_64.
ofry
@ofry
How to check it?
@mati865:matrix.org
jeremyd2019
@jeremyd2019
I'm confused. what I'm finding for x86_64 is a SysV ABI doc for x86_64 describing these models, which fits with what, ie, Linux does, but not necessarily what Windows does
ofry
@ofry
Is any way to check it?
via CLI? or test program?
jeremyd2019
@jeremyd2019
Your comment reminded me of what we currently do for MinGW. Sorry, I should have remembered this earlier. For those targets, we actually use a "small" code model, but we have special handling for variables which we can't prove are DSO-local.
this is from that bug, and 'we' refers to llvm/clang
but basically none of the 'models' from the SysV doc really fit what happens on Windows
ofry
@ofry
@jeremy2019 Could you answer it in https://gitlab.haskell.org/ghc/ghc/-/issues/16780 ?
jeremyd2019
@jeremyd2019
I don't know. I don't entirely understand this 'model' stuff myself. As far as I was concerned, memory models went out with 16-bit DOS/Windows :grin:
ofry
@ofry
-mcmodel=small
Generate code for the small code model: the program and its symbols must be linked in the lower 2 GB of the address space. Pointers are 64 bits. Programs can be statically or dynamically linked. This is the default code model.
can we switch to it anyhow? the program and its symbols must be linked in the lower 2 GB of the address space.
jeremyd2019
@jeremyd2019
if you require that to be true, --default-image-base-low
(which is an option that was invented here to temporarily work around broken things)
If the default image base is below 4GB, Windows will assume the image requires that and will only ASLR it within the lower memory. I don't recall if that's 2GB or 4GB though (sign bit)
but better to fix whatever is making that assumption. I believe Windows is closest to Small PIC:
Small position independent code model (PIC) Unlike the previous models, the
virtual addresses of instructions and data are not known until dynamic link
time. So all addresses have to be relative to the instruction pointer.
Additionally the maximum distance between a symbol and the end of an
instruction is limited to 2
31−2
24−1 or 0x7effffff, allowing the compiler
to use instruction pointer relative branches and addressing modes supported
by the hardware for every symbol with an offset in the range −(224) to 2
24
or 0xff000000 to 0x01000000
BUT, Windows does relocations, and import tables, so that's not entirely true either
jeremyd2019
@jeremyd2019

how about this:

The fact that -mcmodel=small means something else in Windows needs to be documented.

Alternatively, I will propose to define a new value for mcmodel that fits Windows. This model should limit the distance between code and static data to 2 GB so that relative addresses can be used, but allow locating a program at any address.

basically another way to say the same thing, that small PIC is closest, but Windows is kind of its own thing that doesn't exactly fit any of the SysV models
Patrick Storz
@Ede123
@lazka (and others) Have you seen any odd deadlock issues in gtk applications lately?
Since a few weeks we have frequent test failures in our CI due to the tests timing out and I have not yet been able to pin down the issue...
Biswapriyo Nath
@Biswa96
Which gtk version?
Patrick Storz
@Ede123
Latest (3.24.5-1) but might well have started earlier and might well not be related to gtk at all (I have suspicions towards gdbus implementation in glib's GApplication for example)
Christoph Reiter
@lazka
@Ede123 nothing in my CI systems
but I'm also not using gdbus I think, at least not directly
zygon.sisyphus
@zygon.sisyphus:matrix.org
[m]
hi , how dependent is msys2 build system on cygwin/bash? is possible to use only busybox? other shell ?
nushell ?
Mateusz Mikuła
@mati865:matrix.org
[m]
https://reviews.llvm.org/D61670 says GCC defaults to medium for x86_64 mingw but yeah models on windows are different from Linux.
Christoph Reiter
@lazka

hi , how dependent is msys2 build system on cygwin/bash? is possible to use only busybox? other shell ?

makepkg depends on bash

zygon.sisyphus
@zygon.sisyphus:matrix.org
[m]
and PKGBUILD files ?
I see some script
are bash dependendant ?
Mateusz Mikuła
@mati865:matrix.org
[m]
PKGBUILDS are used by makepkg which is Bash dependendant and therefore all PKGBUILDS can use Bash syntax.
zygon.sisyphus
@zygon.sisyphus:matrix.org
[m]
ok, clear.thx.
Unai Martinez-Corral
@umarcor
Can some maintainer please have a look at msys2/MINGW-packages#8934 and hopefully merge? There are some other updates which I'd like to push after that one is built and upstreamed.
Unai Martinez-Corral
@umarcor
Thanks @lazka!