Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
109 user(s) are online (99 user(s) are browsing Forums)

Members: 2
Guests: 107

DrProton, levellord, more...

Headlines

 
  Register To Post  

« 1 ... 13 14 15 (16) 17 18 19 ... 21 »
Re: gcc 9 and 10
Home away from home
Home away from home


See User information
@all
Just to let you know, Max did fix "default strip behaviour" of new binutils, so it reacts the same as adtool's one (same size after default strip as adtools version). But it's even a little better: adtools version for unknown reasons remove after stripping from .rela.text section an "I" flag which original binary had, as well as regroup for no reassons string header sections. Our new one dind't do that, and keep it as it should be, but only strip.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: gcc 9 and 10
Just can't stay away
Just can't stay away


See User information
@kas1e
From https://github.com/migthymax/binutils-gdb/issues/2
Quote:
But I#m bot sure if it even still strips unneeded reloc or just keeps everything to be sure.
The strip from binutils 2.14 kept all relocs, incl. unneeded ones.
I built my own "stripreloc" tool to remove unused/no-op relocs, for example 16 bit r13 relative _SDA_BASE_ ones, from the executables when using ld.
Not 100% sure anymore, but IIRC vlink does remove unused relocs.

Go to top
Re: gcc 9 and 10
Just popping in
Just popping in


See User information
@joerg

Is it just that relic which can be removed. And if so why?
Or how to determine if relics are unneeded?

Go to top
Re: gcc 9 and 10
Just can't stay away
Just can't stay away


See User information
@MigthyMax
When ld creates an executable (ELF EXEC) it resolves all relocs and for example on Unix all relocs are removed from the executable (at least when static linking, may be different if shared objects/linking is used).
On Unix that's possible because ld knows to which memory address the executable will be loaded later: The VirtAddr in the program header.

On AmigaOS it's different, elf.library allocates pages for the executable and has to re-relocate it from the VirtAddr in the executable to the (random) memory address it was loaded to, and for that the relocs still have to be in the executable.
But it's only required for absolute relocs.

Relative relocs like the small data r13/_SDA_BASE_ ones are accessed as "r13 +/- offset" and the offset is always the same, no matter where in memory the _SDA_BASE_ (middle of .sdata and .sbss) is in memory. It's the same for relative relocs in the code, for example if there is a "bl PC + 12340 bytes" function call it's always the same no matter where the .text section is in memory.
Such relative relocs can be removed.

Go to top
Re: gcc 9 and 10
Home away from home
Home away from home


See User information
@All
Check this out plz, maybe you have any idea where we can look after:

https://github.com/migthymax/binutils-gdb/issues/8

It turns out that in new version of LD we have a crash when trying to build any binary with .so attached to it. Even if we didn't use -use-dynld, but just add -L/dir_with_libs and -l<lib> , it makes linker to take firstly .so version of libs as expected, and that cause LD to crash. Builds with *.a versions didn't crashes.

Adtool's version of LD of course handle both cases correctly, so we seem missing something in terms of all this .so / dynld support in new LD

I tried to "gdb" it, and that what i have:

gdb ---args ppc-amigaos-ld.exe test.-o test -L/usr/local/amiga/ppc-amigaos/SDK/clib2/lib /usr/local/amiga/ppc-amigaos/SDK/clib2/lib/crtbegin./usr/local/amiga/ppc-amigaos/SDK/clib2/lib/crtend.-lc
Reading symbols from ppc
-amigaos-ld.exe...
(
gdbrun
Starting program
: /usr/local/amiga/bin/ppc-amigaos-ld.exe test.-o test -L/usr/local/amiga/ppc-amigaos/SDK/clib2/lib /usr/local/amiga/ppc-amigaos/SDK/clib2/lib/crtbegin./usr/local/amiga/ppc-amigaos/SDK/clib2/lib/crtend.-lc
[New Thread 3288.0x17ec]
[New 
Thread 3288.0x2310]
[New 
Thread 3288.0x1b90]
[New 
Thread 3288.0x15d8]

Thread 1 "ppc-amigaos-ld" received signal SIGSEGVSegmentation fault.
0x0000000100436392 in bfd_putb32 (data=<optimized out>, p=0x48at ../../bfd/libbfd.c:836
836       addr
[0] = (data >> 24) & 0xff;
(
gdb)

(
gdbbt full
#0  0x0000000100436392 in bfd_putb32 (data=<optimized out>, p=0x48) at ../../bfd/libbfd.c:836
        
addr 0x48 <errorCannot access memory at address 0x48>
#1  0x0000000100445356 in write_global_sym_plt (h=0xa00025fc0, inf=0x10056f7e0 <link_info>) at ../../bfd/elf32-ppc.c:9744
        
val = <optimized out>
        
rela = {r_offset 16844960r_info 4299380317r_addend 0}
        
loc = <optimized out>
        
reloc_index = <optimized out>
        
plt 0xa000ab3c8
        relplt 
0xa000ab4f8
        dyn 
= <optimized out>
        
info 0x10056f7e0 <link_info>
        
htab 0xa00025650
        ent 
0xa000ad7c8
        doneone 
= <optimized out>
#2  0x0000000100437aaa in bfd_link_hash_traverse (htab=htab@entry=0xa00025650, func=func@entry=0x100445250 <write_global_sym_plt>, info=info@entry=0x10056f7e0 <link_info>) at ../../bfd/linker.c:671
        
0xa00025fc0
        i 
195
#3  0x0000000100453caa in elf_link_hash_traverse (info=0x10056f7e0 <link_info>, f=0x100445250 <write_global_sym_plt>, table=0xa00025650) at ../../bfd/elf-bfd.h:787
        
__PRETTY_FUNCTION__ "elf_link_hash_traverse"
#4  ppc_finish_symbols (info=0x10056f7e0 <link_info>) at ../../bfd/elf32-ppc.c:9813
        
htab 0xa00025650
        ibfd 
= <optimized out>
#5  0x00000001004224da in ppc_finish () at ../../ld/emultempl/ppc32elf.em:239
No locals.
#6  0x000000010041547f in lang_process () at ../../ld/ldlang.c:8210
No locals.
#7  0x00000001004da16c in main (argc=<optimized out>, argv=<optimized out>) at ../../ld/ldmain.c:497
        
emulation = <optimized out>
        
start_time 15000
        flags 
= <optimized out>
(
gdb)



and bfd/libbfd.c:836 is:

832void
833
bfd_putb32 (bfd_vma datavoid *p)
834: {
835:  bfd_byte *addr = (bfd_byte *) p;
836:  addr[0] = (data >> 24) & 0xff;
837:  addr[1] = (data >> 16) & 0xff;
838:  addr[2] = (data >>  8) & 0xff;
839:  addr[3] = data 0xff;
849: }


A full stack-backtrace in GDB shows some strange 0x48 address of memory when we call bfd_pitb32(), but then it comes from write_global_sym_plt() , meaning that we mess something when tries to write things to the elf-binary when .so in use ?


Edited by kas1e on 2023/8/19 19:50:31
Edited by kas1e on 2023/8/19 19:55:48
Edited by kas1e on 2023/8/19 19:59:25
Edited by kas1e on 2023/8/19 19:59:47
Edited by kas1e on 2023/8/19 20:03:08
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: gcc 9 and 10
Just can't stay away
Just can't stay away


See User information
@kas1e
Quote:
Even if we didn't use -use-dynld, but just add -L/dir_with_libs and -l , it makes linker to take firstly .so version of libs as expected, and that cause LD to crash. Builds with *.a versions didn't crashes.
Probably not related to the crash, but on AmigaOS -static has to be the default mode for ld which doesn't use .so but only .a libraries.
Maybe something is wrong in the (internal) specs file.

Issue #6: Using .init_array/.fini_array instead of .ctors/.dtors requires changes in the C libraries, maybe even in elf.library.

Go to top
Re: gcc 9 and 10
Not too shy to talk
Not too shy to talk


See User information
@joerg

Quote:
Issue #6: Using .init_array/.fini_array instead of .ctors/.dtors requires changes in the C libraries, maybe even in elf.library.

Regarding the constructor/destructor change, is it just a simple modification in crtbegin and crtend? After all, it's just a list of pointers that get called if I'm not mistaken.

If we start using the .init_array/.fini_array, we need to add a priority parameter. But other than that, it should be simple, or am I overlooking something?

edit:

I played a little around with gcc and the linker.

it looks like we need an update too adtools as I could not get gcc or the linker use .init_array's..

I tryed with a test source to create .init_array/.fini_array instead of .ctors/.dtors elf sections with this

gcc -c tst.c -mcrt=clib2 -Wl,--init-array -z initarray

but it did not work :/


Edited by rwo on 2023/8/20 15:43:37
“The best thing about a boolean is even if you are wrong, you are only off by a bit.”
Go to top
Re: gcc 9 and 10
Just can't stay away
Just can't stay away


See User information
@rwo
Quote:
Regarding the constructor/destructor change, is it just a simple modification in crtbegin and crtend? After all, it's just a list of pointers that get called if I'm not mistaken.
For statically linked executables it's only the code in crtbegin and the first (~0/-1) and last (NULL) pointers in crtbegin and crtend, but for executables using shared objects elf.library probably has to be changed to add support for .init_array/.fini_array.

Go to top
Re: gcc 9 and 10
Home away from home
Home away from home


See User information
@rwo
Just in case you didnt read whole thread and didnt know where we are: in adtools we already have gcc 11.3, and even latest SDK have it if i remember right.

Also in Max's repo (from where links on tikets are) we exactly fixing latest binutils from 2023 (and they already works, just some issues mentioned above to fix).

I.e. i already use gcc 11.3 + latest binutils from Max, everything fresh in other words.

And init-fini issue is that what we try to fix: it didnt works before , and now, when new binutils and gcc in place want to make this one to work too.

Ps. Adtools repo its both binutils(as,ld, strip, etc) and gcc (gcc, g++, cpp, collect, etc). While gcc part in adtools are up2date already, binutils one were too old, and new one in Max repo. So you build gcc from adtools, and binutils from max, and mix it all in one place.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: gcc 9 and 10
Just popping in
Just popping in


See User information
@rwo

and to add to as1e answer, you should probably even use the clib from afxgroup. Because if a c library can handle fini_/init_array than that one.

And you even need the up to now un released elf.library from eflpipe.

In this three constellation binutils/c lib/elf.libray there might still be some issued regarding that. But we are trying to figure that out.

Go to top
Re: gcc 9 and 10
Just can't stay away
Just can't stay away


See User information
@MigthyMax
Quote:
and to add to as1e answer, you should probably even use the clib from afxgroup. Because if a c library can handle fini_/init_array than that one.
Except for several bugs in the clib2 versions of crtbegin.c and ctrend.c, which the newlib versions don't have, and opening newlib.library instead of clib2.library, the newlib versions of crtbegin/end are basically the same as the clib2 ones, incl. that both have no support for .init_array/.fini_array.

Go to top
Re: gcc 9 and 10
Home away from home
Home away from home


See User information
@joerg
Quote:

Except for several bugs in the clib2 versions of crtbegin.c and ctrend.c


Do you remember which ones ? Pretty possible Andrea already fixed them all

Quote:

Probably not related to the crash, but on AmigaOS -static has to be the default mode for ld which doesn't use .so but only .a libraries.


At least all i can say, is that in Adtools version, if you just do -L<diretory_with_libcs> and -l<lib> at end of compiling line, then, LD will firstly take any .so which find with that name. And if no .so find, then will use .a file. At least that how it for long already. Of course it easy to swith to -static builds to be default (so to not link against .so firstly, but against .a, and only link with .so , if --use-dynld used), but maybe when adtools version were created there were reassons for ? Or just simple mistake ?


Quote:

Maybe something is wrong in the (internal) specs file.


Currently, what i find, is that any try to link against .so library (be it even test.so with 0 bytes of size), our new LD crash. I.e., it doesn't matter what inside of .so file, the matter is the fact that you link against .so. Even if you just do something like:

ppc-amigaos-gcc -o test test.-L. -lf -athread=native


Where in root dir you have libf.so of 0 bytes of size : we still crash. Like, once we involve usage of any .so, this trigger the way of handling dynamic linking , and when start constructing elf file died.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: gcc 9 and 10
Just can't stay away
Just can't stay away


See User information
@kas1e
Quote:
Do you remember which ones ? Pretty possible Andrea already fixed them all
At least in https://github.com/afxgroup/clib2/blob/master/library/crtbegin.c and https://github.com/afxgroup/clib2/blob/master/library/crtend.c no single bug is fixed, it still looks like the utterly broken original clib2 code, and there even is still a crt0.S file in the repository (was only required for the AmigaOS 3.x/m68k version of clib2).
As long as Andrea doesn't re-implement at least 90% of the clib2 functions from scratch it will never be usable.

Go to top
Re: gcc 9 and 10
Home away from home
Home away from home


See User information
@joerg
Quote:

no single bug is fixed, it still looks like the utterly broken original clib2 code

I mean what bugs exactly ?

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: gcc 9 and 10
Home away from home
Home away from home


See User information
@kas1e

it does not close libraries, after being opened, if programs calls Exit(0); perhaps.

Should it setup pr_ExitCode and pr_FinalCode ?

Alert() is not multitasking friendly, perhaps should not be used, but if DOS can't be opened, then perhaps, something else is really wrong, so maybe not, actually a bug.

Perhaps there should be shadow IFace for etch library opened, as there no guarantee, that application has not set the pointer to NULL, before exit. and so it might not be closed twice. if it was opened twice by accident.

(Most applications do not know if Interfaces are valid, when program starts, but some indications that it should not be opened is given when the compiler will give, error about interface/base being defined elsewhere. But I think it should be more failsafe than that.)


Edited by LiveForIt on 2023/8/21 22:07:40
Edited by LiveForIt on 2023/8/21 22:31:41
(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: gcc 9 and 10
Amigans Defender
Amigans Defender


See User information
@joerg

newlib doesn't use the same clib2 mechanism for constructors. newlib doesn't have CONSTRUCTOR defines that clib2 (original too) has. If you try to change the clib2 crtbegin/end files trying to change .ctors/.dtors to ~0/1 nothing will work with current gcc (don't know the ancient version of 20 years ago). If you think that this can be fixed of course feel free to send a pull request
That's the beauty of open source

@LiveForIt

Libraries are always closed correctly inside clib2 function that call main because exit will jump into longjmp that will call the routine that will close the libraries, call the destructors and so on.
Why setup and use pr_ExitCode and pr_FinalCode?
I'll fix the closing routine that will set the pointers to NULL.

i'm really tired...
Go to top
Re: gcc 9 and 10
Just can't stay away
Just can't stay away


See User information
@LiveForIt
Even the very first instruction in afxgroup's clib2 crtbegin.c is bullshit:
int
_start
(STRPTR argstringint32 arglenstruct Library *sysbase) {
    
SysBase = *(struct Library **) 4;
Instead of using the sysbase pointer from the _start() arguments he is intentionally causing a DSI exception to get the SysBase from the DSI handler, which is only there for emulated m68k software, and might be a different SysBase.

Maybe he is trying to prevent software using his clib2 versions from working on multi-core kernels?
At least I can't think of any other reason for using nonsense like that.

But that's not the only one, there are more bugs in it...

Go to top
Re: gcc 9 and 10
Home away from home
Home away from home


See User information
@joerg

SysBase = *(struct Library **) 4;

idltool generates that in all AmigaOS4 libraries.
So perhaps we need updated idltool then?

Why is it a problem to have exception on multicore? The exception handler can FindTask(NULL), and figure out what core its running on, from maybe process or task structure perhaps.

DSI exceptions does not break forbid, and FindTask(NULL) does not need a forbid.

There is function in exec that allows you check if you’re in forbid or not, so you can determine if it's required or not, while you’re in the exception.

Sure unnecessary exceptions are bad, as it will slow down the system, but only good tools and guidelines will resolve that


Edited by LiveForIt on 2023/8/22 22:58:24
Edited by LiveForIt on 2023/8/22 22:59:22
(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: gcc 9 and 10
Amigans Defender
Amigans Defender


See User information

i'm really tired...
Go to top
Re: gcc 9 and 10
Home away from home
Home away from home


See User information
@All
Today build latest EUAE with new BinUtils from Max, and so far all good. So currently what i build with new binutils is SSHTerm and E-UAE : both binaries working.

Through, need to note, that E-UAE by some reassons do have "-Wa,--execstack" in all the makefiles, causing new binutils to spawn a warning which authors of binutils added recently (since v2.39):

Quote:

The ELF linker will now generate a warning message if the stack is made executable. Similarly it will warn if the output binary contains a segment with all three of the read, write and execute permission bits set.
These warnings are intended to help developers identify programs which might be vulnerable to attack via these executable memory regions.


more info: https://www.redhat.com/en/blog/linkers ... table-stacks-and-segments

So either one remove -Wa,--execstack , or, if there is needs for meet the warning just to know what he do.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top

  Register To Post
« 1 ... 13 14 15 (16) 17 18 19 ... 21 »

 




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




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project