Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (salass00)

Bottom

« 1 2 3 4 (5) 6 7 8 ... 91 »

salass00

Re: GDB

Posted on: 2021/2/26 9:30 #81

Just can't stay away

@afxgroup

Quote:

Unlucky fseeko64 is not working correctly on newlib. Don't know if something has broken from your tests but i've tried your p7zip with an 8GB file and it fail. I've tested it with my clib2 version i'm using now and it is working.
So something has changed in newlib code (most probably)

As a test I just used p7zip on my beta installation to create a 6.5GiB archive file from ~11GiB worth of music files and it worked without problems, though it took about 14 hours to finish.

I then ran "7za t" on the archive on both AmigaOS and Ubuntu and both reported that the archive was okay and with no errors.

Then I extracted the archive on AmigaOS using the p7zip port again and this also worked fine with no errors (I also compared md5sums on a couple of the extracted files and they do match the originals).

What file system are you using? JXFS has broken relative seeking as well as other bugs that will never be fixed because it is no longer developed and should not be used anymore. For the tests above I used SFS\2 partitions (ssh2-handler was used to transfer the archive to my Ubuntu system for the test there).

Topic | Forum

salass00

Re: SDL2

Posted on: 2021/2/25 16:39 #82

Just can't stay away

@Capehill

Quote:

And compiled it with g++ version 4.2.4 but didn't hit the same issue. bits/stl_algobase.h includes <utility> which is a header in the C++ standard library and also a directory in the AmigaOS 4 SDK but I don't understand how these get mixed up now.

In older adtools gcc ports the SDK include directories were before the gcc prefix include directories, which is probably why the SDK:include/include_h/utility directory is causing problems. This has been fixed in newer adtools gcc ports since it caused even more problems for C++ support with gcc 6 and later.

Topic | Forum

salass00

Re: GDB

Posted on: 2021/2/25 7:13 #83

Just can't stay away

@billyfish

You should be able to check with "if (fp->_flags & __SL64)" whether the file is 64-bit enabled, just to see if that is the cause of the problem or not.

Topic | Forum

salass00

Re: GDB

Posted on: 2021/2/24 21:11 #84

Just can't stay away

@billyfish

The ftello64() call that returns ESPIPE ("Illegal seek"), is that on a file handle opened by fopen64() or is it a regular fopen() one? If it's the latter it would explain the error.

The newlib 3.1.0 fseeko64() falls back on regular fseeko() if it's called on a FILE pointer not from fopen64(), a feature that I will be adding to our newlib port as well in the next beta release.

Topic | Forum

salass00

Re: SDL2

Posted on: 2021/2/24 17:24 #85

Just can't stay away

@SinanSam460

You should add the dependencies after -lSDL2_image, not before.

Topic | Forum

salass00

Re: GDB

Posted on: 2021/2/24 17:20 #86

Just can't stay away

Quote:

@billyfish
That will help for sure. Can you made such a small test case ? (i just not very well understand issue, so can't myself). If Frederik in interest to deal with in newlib testcase will help.

+1

I tried putting together a simple test program using fopen64(), fseeko64() and ftello64() and it works just fine here (I also added code for reading some data to make sure that it's really at the correct file position).

Also I'm pretty sure I used fseeko64() in my ports of unrar and p7zip and I didn't have any problems there.

Apart from 64-bit vs 32-bit offsets there is little to no difference between the implementations of fseeko64() and fseeko()/fseek() functions.

Topic | Forum

salass00

Re: GDB

Posted on: 2021/2/23 16:00 #87

Just can't stay away

@billyfish

Have you checked what type file_ptr is. If it's 64-bit (long long) then you need to use %lld. If the low 32-bit of pos is printed as direction then that would explain where the 12060 is coming from.

Topic | Forum

salass00

Re: GDB

Posted on: 2021/2/23 14:29 #88

Just can't stay away

@kas1e

The only major difference between clib2 and newlib seek implementations that I can see is that clib2 allows out of bounds seeks by extending the file also if the file is opened as O_RDONLY, whereas newlib only auto extends for O_WRONLY and O_RDWR.

Topic | Forum

salass00

Re: SDL2

Posted on: 2021/2/14 16:06 #89

Just can't stay away

@Raziel

I think you mean Capehill. I've only done a couple of minor fixes to the SDL port and that was years ago.

Recently I've been mainly working on updating our newlib port with code from newlib 3.1.0 leading to better C++ support among other things.

Topic | Forum

salass00

Re: SDL2

Posted on: 2021/2/14 13:14 #90

Just can't stay away

@jabirulo

Quote:

So when new full SDK is out and new/updated GCC and thus stdc++.so then there should be no such requester/problem.

IIRC one of the solutions that was discussed was to build the new libstdc++.so with a different name so that it can be installed next to the old version without causing any conflicts.

Topic | Forum

salass00

Re: SDL2

Posted on: 2021/2/14 9:26 #91

Just can't stay away

@jabirulo

That's because you need to use the updated libstdc++.so of the gcc version you used to compile. Note that this file is not (IIRC) backwards compatible with the one currently in SOBJS: and will break existing programs if put there, so you should include it with your program in PROGDIR:SObjs instead.

If you use static linking you avoid this problem.

Topic | Forum

salass00

Re: DMA buffer for PCI busmaster headache

Posted on: 2021/2/11 15:49 #92

Just can't stay away

@geennaam

Inhibiting caches probably does not do an automatic flush of the affected region.

Topic | Forum

salass00

Re: DMA buffer for PCI busmaster headache

Posted on: 2021/2/11 9:12 #93

Just can't stay away

@geennaam

In addition for the ring buffer you might want to allocate a certain number of memory pages (aligned set to page size, with size a multiple of page size) and use IMMU->GetMemoryAttrs()/IMMU->SetMemoryAttrs() to set the memory as MEMATTRF_CACHEINHIBIT.

You can get the mmu page size using IExec->GetCPUInfoTags().


ULONG get_page_size(void)

{

    ULONG page_size_bits = 0, i;

    ULONG page_size = 0;



    IExec->GetCPUInfoTags(GCIT_ExecPageSize, &page_size_bits, TAG_END);

    for (i = 0; i < 32; i++)

    {

        if (page_size_bits & (1UL << i))

        {

            page_size = (1UL << i);

            break;

        }

    }



    return page_size;

}

Topic | Forum

salass00

Re: DMA buffer for PCI busmaster headache

Posted on: 2021/2/11 8:56 #94

Just can't stay away

@geennaam

The address returned by IExec->AllocVecTags() is a virtual address as seen by the CPU.

To get the physical address of the memory you allocated you need to use the IMMU->GetPhysicalAddress() function from the exec.library "mmu" interface.

The function has to be called from supervisor mode so you will have to do something like:


APTR get_physical_address(APTR virtual)

{

    APTR stack, physical;



    stack = IExec->SuperState();



    physical = IMMU->GetPhysicalAddress(virtual);



    if (stack != NULL)

        IExec->UserState(stack);

}

Topic | Forum

salass00

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/31 10:03 #95

Just can't stay away

@kas1e

Your problem is with dw and dh values (they should not be zero).

Where are they coming from in the code? Most likely there is something wrong in the code that reads or calculates them.

Topic | Forum

salass00

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/31 9:39 #96

Just can't stay away

@kas1e

Quote:

edit: with just "while (SAFE_LEFT_SHIFT(dw,wshift) < sw) wshift++;", same stuck.

Can you print what the values of dw and sw are just before the loop? And dh/sh for the other loop?

If dw is zero and sw is non-zero then the loop will never end because dw will remain zero no matter how much it is shifted.

Also if sw is very large it may be that dw "overflows" before it is larger or equal to sw.

Topic | Forum

salass00

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/31 9:32 #97

Just can't stay away

@kas1e

The third version (i.e. "while (SAFE_LEFT_SHIFT(dw,wshift) < sw) wshift++;").

The first parameter (op) is the value that is to be bit-shifted and the second parameter (amt) is the amount to shift by.

Topic | Forum

salass00

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/31 8:26 #98

Just can't stay away

@kas1e

Try changing to:

loopi(BPP) dst[i] = (tshift < (sizeof(t[i])*8)) ? (t[i] >> tshift) : 0;

If t[i] is signed it should be:

loopi(BPP) dst[i] = (tshift < (sizeof(t[i])*8)) ? (t[i] >> tshift) : ((t[i] < 0) ? -1 : 0);

If there is a lot of this type of code you may want to consider using macros like this (from newlib 3.1.0 libm source code):


/* Macros to avoid undefined behaviour that can arise if the amount

   of a shift is exactly equal to the size of the shifted operand.  */



#define SAFE_LEFT_SHIFT(op,amt)                    \

  (((amt) < 8 * sizeof(op)) ? ((op) << (amt)) : 0)



#define SAFE_RIGHT_SHIFT(op,amt)                \

  (((amt) < 8 * sizeof(op)) ? ((op) >> (amt)) : 0)

Note that the SAFE_RIGHT_SHIFT needs to be modified if it's to work with signed values (where sign bit should be copied into new bits that are shifted in from the left).

Topic | Forum

salass00

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/31 8:11 #99

Just can't stay away

@kas1e

Probably the same problem with the next loop.

Addr2line is not that accurate so it can be off by a few lines/statements.

Topic | Forum

salass00

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/31 7:48 #100

Just can't stay away

@kas1e

IIRC result of shift operation is undefined when wshift >= (sizeof(dw)*8).

Try changing the loop to:

while (wshift < (sizeof(dw)*8) && (dw << wshift) < sw) {
wshift++;
}

Topic | Forum

Top

« 1 2 3 4 (5) 6 7 8 ... 91 »