Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
107 user(s) are online (65 user(s) are browsing Forums)

Members: 0
Guests: 107

more...

Headlines

 
  Register To Post  

« 1 (2)
Re: The ADTOOLS thread
Quite a regular
Quite a regular


See User information
@afxgroup

Okay, can you please add a test that proves that CLIB2 SO works? You can add it to the linked repository above.

Can you show that the order of the constructors and destructor are correct also?

You just need to close that repo above and add a new test into tests.

Or, just give me the sources and I'll add it.

Thanks.

If liberty means anything at all, it means the right to tell people what they do not want to hear.
George Orwell.
Go to top
Re: The ADTOOLS thread
Quite a regular
Quite a regular


See User information
@all
@afxgroup

Is anyone able to provide any tests to the referenced repo before I apply any PRs to the main-line adtools?

The tests can be added to the main-line repo, but for now, you can add them (or just provide me the source code so that I can add them) to my referenced repo above.

As far as I know, at the moment, static libraries are okay, newlib and clib2. shared o is okay newlib, but not clib2.

@afxgroup
One way or another, the current HEAD of clib2 needs to be fixed so that -Werror does not cause an issue wrt. the "time" structure cast we talked about.

If liberty means anything at all, it means the right to tell people what they do not want to hear.
George Orwell.
Go to top
Re: The ADTOOLS thread
Amigans Defender
Amigans Defender


See User information
As I wrote I can confirm that shared objects are working but since the elf.library has not been released is not possible to test them.
The amigaos.h file is correct so don't worry about it.
-Werror in beta10 has been removed. I'm waiting to merge it into master since there are some things I want to fix

i'm really tired...
Go to top
Re: The ADTOOLS thread
Just can't stay away
Just can't stay away


See User information
@afxgroup
Quote:
As I wrote I can confirm that shared objects are working but since the elf.library has not been released is not possible to test them.
Whatever the problem with old elf.library versions was, as far as I understood it the beta versions of it you are currently using don't call the __shlib_call_constructors() and __shlib_call_destructors() functions of shared objects any more but use something else internally.
That's OK for some beta testing, but of course such extremely broken versions of elf.library must never be used for any public release.

Go to top
Re: The ADTOOLS thread
Amigans Defender
Amigans Defender


See User information
It is calling both functions. Shcrtbegin/end are used both when using -use-dynld. Don't ask me why it was broken in the past. I don't know how elf.library was working internally

i'm really tired...
Go to top
Re: The ADTOOLS thread
Quite a regular
Quite a regular


See User information
@afxgroup
https://github.com/3246251196/adtools_testing.git

You can see that I have added a 2nd test there: "2_capehill_adtools_issue_139_test_code"

You should be able to clone that while thing, run "./4afx" in the background, be left with LHA files in that test folder, transfer them to your AmigeOne, execute them and have the successfully run - iff we are all set to go.

If liberty means anything at all, it means the right to tell people what they do not want to hear.
George Orwell.
Go to top
Re: The ADTOOLS thread
Quite a regular
Quite a regular


See User information
I have spent some time creating a testing framework that we can hopefully use for the future of ADTOOLS etc.

https://github.com/3246251196/adtools_testing

Cloning this, CD'ing into it and running:
./adt -b
./adt -t

Copying over the adt_tests.lha to your AmigaOne machine, extracting it, and running
execute run_all.script

Should be all that is needed. Run:
adt

on your linux machine for more information. The "user.script" is purposefully commented out to reduce the risk of GURU during the invocation of tests.

Now, I want to talk about the test (in the context of NEWLIB):
2_capehill_adtools_issue_139_test_code

This was test written to test shared object constructors and destructors. There are two issues I see with this test:

When running the run#?.script for each STATIC and DYNAMIC:
In both the STATIC and DYNAMIC versions, I notice that once the MAIN function ends then no printing from STDOUT is respected, despite indirection. In other words, any printing to STDOUT from the destructor is not written to the file via indirection. So, I would like to know why redirection does not work in both of these cases.

Forgetting the run#?.script for a moment; when invoking the executable directly by running main#?.exe in each STATIC and DYNAMIC the STATIC version works okay but the DYNAMIC version only displays constructor "ctor" and not "ctor2".

I only have the public version of ELF.LIBRARY, so I am not sure if that is the issue.

To reproduce this, follow the steps listed at the begging of this post.

===

Once more, I invite anyone to add more tests to this repository - with a Pull Request I will happily pull. I will also try and get this framework integrated into ADTOOLS.

If liberty means anything at all, it means the right to tell people what they do not want to hear.
George Orwell.
Go to top
Re: The ADTOOLS thread
Just can't stay away
Just can't stay away


See User information
@rjd324
Quote:
In both the STATIC and DYNAMIC versions, I notice that once the MAIN function ends then no printing from STDOUT is respected, despite indirection. In other words, any printing to STDOUT from the destructor is not written to the file via indirection. So, I would like to know why redirection does not work in both of these cases.
After main() ends _exit() is called which closes/frees all C library stuff, including the stdio streams.
Even if interfaces and libraries are released/closed as well IDOS should still be available and working (IIRC I didn't set the interface pointers to NULL), use something like IDOS->Printf() instead for debugging output. But in case that doesn't work either the only way would be using IExec->DebugPrintF().

Edit: OTOH C library functions of course have to work in sobjs destructor functions, I can't check it since I don't have access to the newlib.library (nor any other AmigaOS) sources any more, but maybe the order of first calling __shlib_call_destructors() and then _exit() is wrong in newlib.


Edited by joerg on 2023/4/11 19:21:55
Go to top
Re: The ADTOOLS thread
Quite a regular
Quite a regular


See User information
@joeg

Using Printf from DOS worked and I updated the repository.

The test for STATIC NEWLIB with my public elf.library continues to show the second constructor not being called.

If liberty means anything at all, it means the right to tell people what they do not want to hear.
George Orwell.
Go to top
Re: The ADTOOLS thread
Home away from home
Home away from home


See User information
@rjd324

Quote:

Using Printf from DOS worked and I updated the repository.

The test for STATIC NEWLIB with my public elf.library continues to show the second constructor not being called.


Use Objdump or similar to verify the constructor array doesn't not have any NULLs in it.

The constructor calling code, assumes the array is terminated at both ends by a NULL pointer, but in some unusual cases there can be NULL in the middle which messes it up.

good:

NULL
Const1
Const2
NULL

bad:

NULL
Const1
NULL
Const2
NULL

Go to top
Re: The ADTOOLS thread
Just can't stay away
Just can't stay away


See User information
@broadblues
Quote:
good:

NULL
Const1
Const2
NULL
That's wrong as well, according to the ELF standard it has to be
~0/-1 (0xFFFFFFFF on 32 bit systems, 0xFFFFFFFFFFFFFFFF on 64 bit systems)
Const1
Const2
NULL

Even if neither the __shlib_call_constructors()/destructors() functions nor elf.library may check it it should be fixed, newer versions of binutils might depend on it.

Go to top
Re: The ADTOOLS thread
Quite a regular
Quite a regular


See User information
BTW, working with @walkero and @afxgroup

The repo https://github.com/3246251196/adtools_testing

Now also provides an easy way to build a cross compiler with a single command. It handles dependency checks etc.

./adt -b


Is the only command you would need to run on your machine to build the latest cross compiler ready for use.

For more options, run

./adt

If liberty means anything at all, it means the right to tell people what they do not want to hear.
George Orwell.
Go to top
Re: The ADTOOLS thread
Just popping in
Just popping in


See User information
@rjd324

Thank you for providing such an easy solution for compiling gcc. I managed to compile a cross-compiler using the normal adtools repository, but the script makes everything much easier.

Sadly, it does not seem to work on aarch64 (Raspberry Pi). It would be great if you could make it work on this platform, too.

Go to top
Re: The ADTOOLS thread
Quite a regular
Quite a regular


See User information
Thanks for trying it. You can try the latest version, or just see my reply to the issue you raised. Not sure how far it will get; let's see.

If liberty means anything at all, it means the right to tell people what they do not want to hear.
George Orwell.
Go to top
Re: The ADTOOLS thread
Just popping in
Just popping in


See User information
@rjd324

Thank you, with your latest change I could generate a cross-compiler.

Some of the tests fail to build, though. I am looking into it.

Go to top
Re: The ADTOOLS thread
Quite a regular
Quite a regular


See User information
Please add more tests by all means.

I also get failures on < gcc11 or with a different SDK, cannot remember which.

If liberty means anything at all, it means the right to tell people what they do not want to hear.
George Orwell.
Go to top

  Register To Post
« 1 (2)

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project