gcc 9 and 10

	Bottom Previous Topic Next Topic
Register To Post

« 1 ... 12 13 14 (15) 16 17 18 ... 21 »

kas1e

Re: gcc 9 and 10

Posted on: 2023/8/10 19:23 #281

Home away from home

@joerg

Quote:

I don't know if the default for the AmigaOS 4.x port of strip was ever changed, but 15 years ago on AmigaOS 4.x only using "strip --strip-unneeded" worked.

It works as expected in adtools version, with all the flags, and even "--strip-unneeded-rel-relocs" works for us in adtools version.

Join us to improve dopus5!
AmigaOS4 on youtube

joerg

Re: gcc 9 and 10

Posted on: 2023/8/10 19:33 #282

Just can't stay away

@geennaam
Quote:

Strip -s works fine for me.

If it does, what else should be the problem in https://github.com/migthymax/binutils-gdb/issues/2 ?
Original "strip -s/--strip-all" removes all symbols, which of course can't work on AmigaOS and you have to use "strip --strip-unneeded" instead.

geennaam

Re: gcc 9 and 10

Posted on: 2023/8/10 19:39 #283

Quite a regular

@joerg
That issue report seems to apply to a cross compiler environment. I always use strip -s on my binaries and it indeed strips all symbols as far as possible. No idea why it can't work on amigaos. My binaries work just fine.

joerg

Re: gcc 9 and 10

Posted on: 2023/8/10 19:42 #284

Just can't stay away

@geennaam
An AmigaOS 4.x executable without the "_start" symbol can't work.

It's something different for libraries, devices, etc., started by struct Resident instead, in case you are using "strip -s" for example on your nvme.device.

geennaam

Re: gcc 9 and 10

Posted on: 2023/8/10 19:44 #285

Quite a regular

@joerg

I also use it on tools that come with my drivers. Like the hdmixer or Nvme diagnostics. So apparently strip -s strips all symbols that aren't strictly necessary from a functional pov.

kas1e

Re: gcc 9 and 10

Posted on: 2023/8/10 20:03 #286

Home away from home

@geennaam
Quote:

That issue report seems to apply to a cross compiler environment.

It's not related to crocc or not cross-compiler , it's a new issue with new binutils which we need to fix.

Current public adtool's "strip" from 2.32 binutils works fine (and always works fine) be it cross or not cross-compilers of course. Issue above are about _new_ binutitils, with this _new_ issue.

@joerg
Quote:

If it does, what else should be the problem in https://github.com/migthymax/binutils-gdb/issues/2 ?
Original "strip -s/--strip-all" removes all symbols, which of course can't work on AmigaOS and you have to use "strip --strip-unneeded" instead.

Issue is that this is new binutils, which changed in major and minor parts, and we just didn't patch things properly everywhere to make it works : that what we need now, to find what we do wrong, or what we not do which causing such _new_ issue with this _new_ binutils.

I.e. there no problems with adtools, and with strip from adtools. What i point out now, is _new_ binutils (not from adtools), with _new_ issue in "strip" command. We probably just didn't do something correctly.

I see that adtools have some patches for strip:
0006-Introduced-strip-unneeded-rel-relocs.patch
and
0007-Keep-symbols-for-stripped-sections.-This-is-importan.patch

Maybe this 0007 one is that one which should make it works.

Join us to improve dopus5!
AmigaOS4 on youtube

joerg

Re: gcc 9 and 10

Posted on: 2023/8/10 20:11 #287

Just can't stay away

@kas1e
Try if using "strip --strip-unneeded" instead of just "strip" (= "strip -s/--strip-all") works with the new binutils.

Quote:

Maybe this 0007 one is that one which should make it works.

Both 0006 and 0007 should be required.

kas1e

Re: gcc 9 and 10

Posted on: 2023/8/10 20:15 #288

Home away from home

@Joerg
Quote:

strip --strip-unneeded

Wow, that one works !

What did it mean ? That in adtools this just set to be as default behavior in strip ?

Join us to improve dopus5!
AmigaOS4 on youtube

MigthyMax

Re: gcc 9 and 10

Posted on: 2023/8/11 8:59 #289

Just popping in

@joerg

Quote:

.text must not be writable.
If elf.library ignores it for code it may not be a problem, but if it doesn't and allocates the code in writable memory it's a problem.

Quote:

Read-only (.text, .rodata, ...) and writable (.sbss) sections mustn't be in the same segment.
Executable (.text) and non-executable (everything else) sections mustn't be in the same segment either.

Both shouldn't be a problem to be fixed. Could you open a or two issues on the github project.

kas1e

Re: gcc 9 and 10

Posted on: 2023/8/11 16:55 #290

Home away from home

@Max
Quote:

Both shouldn't be a problem to be fixed. Could you open a or two issues on the github project.

I create 2 tickets on github about, so Joerg have no needs to worry. Through, if you read my next post there, it seems it was like this all the time on amigaos4, from the beginning.

Edited by kas1e on 2023/8/11 17:32:19

Join us to improve dopus5!
AmigaOS4 on youtube

kas1e

Re: gcc 9 and 10

Posted on: 2023/8/11 17:29 #291

Home away from home

@Joerg

I build assembler test case (so just "as" and "ld" no "gcc" involved) , with binutils 2.14 from an old SDK, that what i have when i "readelf -e test_2_14":


$ ppc-amigaos-readelf -e test_2_14

ELF Header:

  Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00

  Class:                             ELF32

  Data:                              2's complement, big endian

  Version:                           1 (current)

  OS/ABI:                            UNIX - System V

  ABI Version:                       0

  Type:                              EXEC (Executable file)

  Machine:                           PowerPC

  Version:                           0x1

  Entry point address:               0x90

  Start of program headers:          52 (bytes into file)

  Start of section headers:          1468 (bytes into file)

  Flags:                             0x0

  Size of this header:               52 (bytes)

  Size of program headers:           32 (bytes)

  Number of program headers:         1

  Size of section headers:           40 (bytes)

  Number of section headers:         15

  Section header string table index: 12



Section Headers:

  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al

  [ 0]                   NULL            00000000 000000 000000 00      0   0  0

  [ 1] .text             PROGBITS        00000074 000074 00048c 00 WAX  0   0  4

  [ 2] .rela.text        RELA            00000000 000814 0002e8 0c     13   1  4

  [ 3] .rodata           PROGBITS        00000500 000500 000034 01 AMS  0   0  4

  [ 4] .__newlib_version PROGBITS        00000534 000534 000008 00   A  0   0  4

  [ 5] .sdata2           PROGBITS        0000053c 00053c 000000 00   A  0   0  4

  [ 6] .data             PROGBITS        0000053c 00053c 000000 00  WA  0   0  1

  [ 7] .ctors            PROGBITS        0000053c 00053c 000008 00  WA  0   0  4

  [ 8] .dtors            PROGBITS        00000544 000544 000008 00  WA  0   0  4

  [ 9] .sdata            PROGBITS        0000054c 00054c 000000 00  WA  0   0  4

  [10] .sbss             NOBITS          0000054c 00054c 000024 00  WA  0   0  4

  [11] .bss              NOBITS          00000570 00054c 000000 00  WA  0   0  1

  [12] .shstrtab         STRTAB          00000000 00054c 00006e 00      0   0  1

  [13] .symtab           SYMTAB          00000000 000afc 000240 10     14  16  4

  [14] .strtab           STRTAB          00000000 000d3c 0000c1 00      0   0  1

Key to Flags:

  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),

  L (link order), O (extra OS processing required), G (group), T (TLS),

  C (compressed), x (unknown), o (OS specific), E (exclude),

  D (mbind), v (VLE), p (processor specific)



Program Headers:

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align

  LOAD           0x000074 0x00000074 0x00000074 0x004d8 0x004fc RWE 0x4



 Section to Segment mapping:

  Segment Sections...

   00     .text .rodata .__newlib_version .sdata2 .data .ctors .dtors .sbss

As far as i can see, it was the same : .text were even back then marked as writable, and the same was about readonly and writable sections being in one segment, same as executable and non-executable sections being in one segment as well.

That with bintuils 2.14 , from 2003.06.12. So it was like this always, then , and this is not issue because of which baserel stop working ?

At least from the look at dumps, i can't see that in 2.14 it elf files were constructed anyhow different for us.

Join us to improve dopus5!
AmigaOS4 on youtube

joerg

Re: gcc 9 and 10

Posted on: 2023/8/11 17:39 #292

Just can't stay away

@kas1e
Maybe readelf -e doesn't display enough information, try readelf -g -l -t.

Or more likely
Quote:

I build assembler test case (so just "as" and "ld" no "gcc" involved)

The assembler code is wrong, try building some simple, hello world or similar, C code (with GCC 4.0.4 or older!) instead.

Someone

wrote an article on https://wiki.amigaos.net/wiki/The_Hacking_Way:_Part_1_-_First_Steps with


7/0.Work:> readelf -S hello

There are 7 section headers, starting at offset 0x198:

 

Section Headers:

  [Nr] Name    Type            Addr     Off    Size   ES Flg Lk Inf Al

  [ 0]          NULL        00000000 000000 000000 00      0   0  0

  [ 1] .text             PROGBITS        00000054 000054 0000f8 00  AX  0   0  1

output: .text isn't writable there.

Edited by joerg on 2023/8/11 18:11:23

kas1e

Re: gcc 9 and 10

Posted on: 2023/8/11 18:42 #293

Home away from home

@Joerg
Quote:

The assembler code is wrong, try building some simple, hello world or similar, C code (with GCC 4.0.4 or older!) instead.

Yes, i use pure libc's helloworld:


$ cat test.s

   .globl main

main:

        lis %r3,.msg@ha          #

        la %r3,.msg@l(%r3)       # printf("aaaa");

        bl printf                #



        li %r3,0                 # exit(0);

        bl exit                  #



.msg:

        .string "aaaa"

Quote:

Someone wrote an article on

haha :) that was long ago indeed, but the part of code you quote about .text, happens because i do use special ldscript for:


SECTIONS

 {

   . = SIZEOF_HEADERS;

   .text           : { *(.text) }

 }

With this ldscript used, the .text segment is AX. Once i use defaults (so some default ldscript), then, the .text segment is WAX. And does not matter what version of gcc/binutils i use, even on 2.14 it's the same : default ldscript = WAX, my own one = AX.

EDIT: I even tried to build test case with new binutils, but just with my own ldscript : and it's AX !

This is probably mean, that prebuild ldscripts (the default ones LD uses) are guilty of. Right ?

Edited by kas1e on 2023/8/11 18:58:16
Edited by kas1e on 2023/8/11 18:59:28
Edited by kas1e on 2023/8/11 19:01:43

Join us to improve dopus5!
AmigaOS4 on youtube

joerg

Re: gcc 9 and 10

Posted on: 2023/8/11 19:07 #294

Just can't stay away

@kas1e
Quote:

Yes, i use pure libc's helloworld:

Bug: .text is missing before .globl main.
For example check the assembler code in your "Assembler programming without libc" in https://wiki.amigaos.net/wiki/The_Hacking_Way:_Part_1_-_First_Steps
between the .macro CALLOS and .global _start _start:

kas1e

Re: gcc 9 and 10

Posted on: 2023/8/11 19:13 #295

Home away from home

@joerg
That when you use _start (so no libc.a), with libc it's not important, but yeah, added for sake of tests and still issue the same: with default ldscripts WAX, with my own - AX.

Join us to improve dopus5!
AmigaOS4 on youtube

kas1e

Re: gcc 9 and 10

Posted on: 2023/8/13 18:09 #296

Home away from home

@All
Can anyone point me out where in adtools/binutils patches, the changes to "strip" were done, so by default it acts like "--strip-unneeded", and not like "-s" ? Just can't find such change in patches, but definitely strip acts like "--strip-unneeded" by default in adtools version.

Join us to improve dopus5!
AmigaOS4 on youtube

joerg

Re: gcc 9 and 10

Posted on: 2023/8/13 18:22 #297

Just can't stay away

@kas1e
I don't know if there are patches, and if yes where, but if you check for example
https://sourceforge.net/p/adtools/code ... s/2.14/binutils/objcopy.c
there are parts like


if (strip_symbols == STRIP_ALL)

      {

          if (strcmp(name, "_start") == 0 || strcmp(name, "__amigaos4__") == 0 || strcmp(name, "_SDA_BASE_") == 0)

      keep = 1;

    else

    keep = 0;

      }


/* Never, ever, strip reloc data on the Amiga! */

      if (strip_symbols == STRIP_ALL &&

      bfd_get_flavour(obfd) != bfd_target_amiga_flavour)

    {

MigthyMax

Re: gcc 9 and 10

Posted on: 2023/8/13 18:57 #298

Just popping in

@joerg

Do you know why the __amigaos4__ and __SDA_BASE__ needs to kept?
The __start__ is is clear to be kept, because it defines the entry point of the executable.

joerg

Re: gcc 9 and 10

Posted on: 2023/8/13 19:03 #299

Just can't stay away

@MigthyMax
Isn't __SDA_BASE__ the pointer to the small data (.sbss/.sdata)?
If it isn't, it may be the pointer to the baserel data.

Not sure about __amigaos4__, maybe it's just checked to make sure an ELF file is an AmigaOS 4.x executable and not something else.
There is no AmigaOS defined for the OS in ELF executables (EI_OSABI), AmigaOS is using UNIX SysV (0) instead.

Edit: __SDA_BASE__ is the small data pointer, from the amigaos.* linker scripts:


/* We want the small data sections together, so single-instruction offsets

     can access them all, and initialized data all before uninitialized, so

     we can shorten the on-disk segment size.  */

  .sdata          :

  {

    _SDA_BASE_ = . + 0x8000;

    *(.sdata .sdata.* .gnu.linkonce.s.*)

  }

  _edata = .; PROVIDE (edata = .);

  __bss_start = .;

  .sbss           :

  {

    *(.dynsbss)

    *(.sbss .sbss.* .gnu.linkonce.sb.*)

    *(.scommon)

  }

Edit2: You can close https://github.com/migthymax/binutils-gdb/issues/5
I thought that there would have been (at least) 3 segments (read-only executable, read-only non-executable and writable), but according to Futaura it always were only 2 segments (read-only and writable).

Edited by joerg on 2023/8/13 19:23:14
Edited by joerg on 2023/8/13 19:27:27
Edited by joerg on 2023/8/13 20:12:25

Futaura

Re: gcc 9 and 10

Posted on: 2023/8/16 10:47 #300

Just popping in

Quote:

joerg wrote:

Edit2: You can close https://github.com/migthymax/binutils-gdb/issues/5
I thought that there would have been (at least) 3 segments (read-only executable, read-only non-executable and writable), but according to Futaura it always were only 2 segments (read-only and writable).

Of course, nobody should take my word for it - however, "readelf -l" on most (if not all) OS components will show this to be the case. Two segments, unless there is no rw data at all, in which case a single read-only executable segment (e.g. "C:Version").

IBrowse, AmiSSL and Warp Datatype Developer

Register To Post	« 1 ... 12 13 14 (15) 16 17 18 ... 21 »
	Top Previous Topic Next Topic

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