Giter VIP home page Giter VIP logo

Comments (9)

fjtrujy avatar fjtrujy commented on August 13, 2024 1

Hello @joel16,
As you can check now in the CI/CD all the examples are being compiled properly, even the pspsdk/src/samples/net/simple.
The issue has been solved after upgrading newlib to latest version.

Thanks

from pspsdk.

carstene1ns avatar carstene1ns commented on August 13, 2024

Seems they got nuked with some update. You could try replacing them with __builtin_bswap16 for the short versions and __builtin_bswap32 for the long versions in in.h.

from pspsdk.

joel16 avatar joel16 commented on August 13, 2024

Yup that seems to be my only option for now, but this should be addressed IMO.

from pspsdk.

f0rtesque avatar f0rtesque commented on August 13, 2024

Is there a recommended fix for this?

I have updated the newlib in my own fork for the newlib repo f0rtesque/newlib@d47be77

The toolchain compiles successfully aswell as any code the referes to htons(x) htonl(x) ntohs(x) and ntohl(x) where the non-existent builtin methods exist. But I'm not really happy with it. Ideally I'd like the __builtin_allegrex_wsbh and __builtin_allegrex_wsbw to be available.

From reading the gcc changelogs the wsbh and wsbw opcodes were added to the mips configuration in the upstream gcc somewhere around 2013, which I'm assuming thats why the definitions in the gcc patch were removed. I'm not familiar with the internal workings of the gcc compiler but I'm trying to add the wsbw and wsbh methods.

I've looked at the builtin bswap32 and bswap16 and they get compiled to quite a few instructions

bswap16

089004e4 02 00 c2 97     lhu        v0,local_1e(fp)
089004e8 00 1a 02 00     sll        v1,v0,0x8
089004ec 02 00 c2 97     lhu        v0,local_1e(fp)
089004f0 02 12 02 00     srl        v0,v0,0x8
089004f4 25 10 62 00     or         v0,v1,v0
089004f8 00 00 c2 a7     sh         v0,0x0(fp)=>local_20

and bswap32 get compile to the use the __bswapsi2 function

**************************************************************
*                          FUNCTION                          *
**************************************************************
uint __stdcall __bswapsi2(uint param_1)
assume gp = 0x890b7d0
uint              v0:4           <RETURN>
uint              a0:4           param_1
__bswapsi2                                      XREF[3]:     Entry Point(*), main:08900540(c), 
                                                                                          .debug_frame::00000660(*)  
08902bb8 00 2e 04 00     sll        a1,param_1,0x18
    assume gp = <UNKNOWN>
08902bbc 02 16 04 00     srl        v0,param_1,0x18
08902bc0 03 1a 04 00     sra        v1,param_1,0x8
08902bc4 25 10 45 00     or         v0,v0,a1
08902bc8 00 ff 63 30     andi       v1,v1,0xff00
08902bcc 25 10 43 00     or         v0,v0,v1
08902bd0 00 22 04 00     sll        param_1,param_1,0x8
08902bd4 ff 00 03 3c     lui        v1,0xff
08902bd8 24 20 83 00     and        param_1,param_1,v1

I'll continue to work on the gcc changes and make a pull request to the toolchain repo if I can get it working. Does anyone have some good resources on gcc internals?

from pspsdk.

carstene1ns avatar carstene1ns commented on August 13, 2024

Yeah, using the bswap methods was a quick fix to get it working, however should be properly fixed.
Given they are available in current gcc ,we likely just lack some ifdef or such to actually have them.

from pspsdk.

carstene1ns avatar carstene1ns commented on August 13, 2024

@fjtrujy: I sincerely doubt an updated newlib makes missing functions magically available.
In this commit a workaround was added instead: pspdev/newlib@6dc26bb
What you did was just copying this over to pspsdk.

from pspsdk.

fjtrujy avatar fjtrujy commented on August 13, 2024

@fjtrujy: I sincerely doubt an updated newlib makes missing functions magically available. In this commit a workaround was added instead: pspdev/newlib@6dc26bb What you did was just copying this over to pspsdk.

Hello @carstene1ns,
I didn't want to say that the newlib changes are making these functions magically appear.
I just followed the first post, where @joel16 complained that the example pspsdk/src/samples/net/simple wasn't working, and it was showing compilation errors, however, it currently is compiling properly, as you can see here:

https://github.com/pspdev/pspsdk/runs/4321341472?check_suite_focus=true

rm -f netsample.elf  main.o PARAM.SFO EBOOT.PBP EBOOT.PBP
psp-gcc -I. -I/usr/local/pspdev/psp/include -I/usr/local/pspdev/psp/sdk/include -G0 -O0 -Wall -g -D_PSP_FW_VERSION=150   -c -o main.o main.c
main.c: In function ‘start_server’:
main.c:147:54: warning: passing argument 3 of ‘accept’ from incompatible pointer type [-Wincompatible-pointer-types]
  147 |      new = accept(sock, (struct sockaddr *) &client, &size);
      |                                                      ^~~~~
      |                                                      |
      |                                                      size_t * {aka unsigned int *}
In file included from /usr/local/pspdev/psp/sdk/include/netinet/in.h:46,
                 from /usr/local/pspdev/psp/sdk/include/pspnet_resolver.h:21,
                 from main.c:21:
/usr/local/pspdev/psp/sdk/include/sys/socket.h:256:47: note: expected ‘socklen_t * restrict’ {aka ‘long unsigned int * restrict’} but argument is of type ‘size_t *’ {aka ‘unsigned int *’}
  256 | int accept(int, struct sockaddr * __restrict, socklen_t * __restrict);
      |                                               ^
psp-gcc -I. -I/usr/local/pspdev/psp/include -I/usr/local/pspdev/psp/sdk/include -G0 -O0 -Wall -g -D_PSP_FW_VERSION=150  -L. -L/usr/local/pspdev/psp/lib -L/usr/local/pspdev/psp/sdk/lib  -Wl,-zmax-page-size=128  main.o  -lpspdebug -lpspdisplay -lpspge -lpspctrl -lpspsdk -lpspnet -lpspnet_apctl -o netsample.elf
psp-fixup-imports netsample.elf
mksfo 'netsample' PARAM.SFO
psp-strip netsample.elf -o netsample_strip.elf
pack-pbp EBOOT.PBP PARAM.SFO NULL  \
	NULL NULL NULL  \
	NULL  netsample_strip.elf NULL
[0]        408 bytes | PARAM.SFO
[1]          0 bytes | NULL
[2]          0 bytes | NULL
[3]          0 bytes | NULL
[4]          0 bytes | NULL
[5]          0 bytes | NULL
[6]     103816 bytes | netsample_strip.elf
[7]          0 bytes | NULL

Anyway, the "new" newlib 4.1.0, has been done from the very scratch by me, and over there I don't have defined any specific __builtin_allegrex function. You can see the changes here:
pspdev/newlib@dd3c854

Now newlib changes are super tiny, being the best for future upgrades.

Thanks

from pspsdk.

carstene1ns avatar carstene1ns commented on August 13, 2024

@fjtrujy You did not understand correctly. __builtin_allegrex_wsbh and friends have been part of the gcc patch, which are missing since some time.
The example has been compiled successfully with my workaround for some time as well.

All you say is that "your" newlib is super and everything is working, while not understanding the real problem here.

This really bugs me, because you seem to think you solved all problems, while creating some others. For example when you removed the preprocessor define PSP, just because such thing is not present for the PS2 gcc. I bet this broke some custom Makefiles, which you seem not to care about.

from pspsdk.

fjtrujy avatar fjtrujy commented on August 13, 2024

@fjtrujy You did not understand correctly. __builtin_allegrex_wsbh and friends have been part of the gcc patch, which are missing since some time.

The example has been compiled successfully with my workaround for some time as well.

All you say is that "your" newlib is super and everything is working, while not understanding the real problem here.

This really bugs me, because you seem to think you solved all problems, while creating some others. For example when you removed the preprocessor define PSP, just because such thing is not present for the PS2 gcc. I bet this broke some custom Makefiles, which you seem not to care about.

Once again I'm not saying anything against this missing instructions, I just said that the example was compiling ( I didn't know if it was compiling before....)

Regarding the PSP flag, we can put it back (I actually don't mind), but obviously we CAN'T assure that all the software are still compiling.

The maximum we can do is to check that our repositories (PSPDEV ones) are working, and they are.

from pspsdk.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.