English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. C/C++

 
 
Thread Tools
Old 26 December 2017, 19:50   #561
bebbo
Registered User

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 307
Quote:
Originally Posted by phx View Post
Ok, you are right. There is nothing which explicitely calls such a structure being illegal. Nevertheless it is... not correct.
What is correct? The executables are running fine. Is that incorrect?

Quote:
Originally Posted by phx View Post
What kind of executable should a linker create from such an object? Unlike ELF (.debug*) the hunk-format has no segments which are ignored by the loader. Which means, assuming a linker would emit such an executable, it had to include a segment with only HUNK_DEBUG and RELOC32 in it.
Oh, the HUNK_DEBUG is ignored - simply skipped using it's length.

Quote:
Originally Posted by phx View Post
When you look at the AmigaOS LoadSeg() code you see that it only recognizes HUNK_CODE/DATA/BSS hunks as the basis for a subsequent relocation hunk. So your plan to make the OS relocate a HUNK_DEBUG won't work. And even if this is not your plan and you want to relocate the DEBUG hunk with your debugger instead, my guess would be that the system will crash, because there is no valid pointer in the loader's segment table when encountering these relocations.
The relocation is done by the linker. The final executable may contain 'standalone' DEBUG_HUNKS, but the OS does not complain.

Quote:
Originally Posted by phx View Post
Are you saying the executable code depends on information from a DEBUG hunk? That's really strange. Such information should be for a debugger only, and can usually be stripped without a problem.
And you can strip the DEBUG_HUNKs from the executables without any problem. Only the linker needs that information (any maybe a debugger - is there a working gdb?)

Quote:
Originally Posted by phx View Post
Otherwise, then I don't understand why it should be a DEBUG hunk at all. When the program needs it, put it into HUNK_DATA.
(I have the feeling there are many misunderstandings, but I didn't read anything in this thread before my first post).

I didn't expect that, but you are right! It strips everything, though, also the HUNK_RELOC32. Which is sort of good, so the executable doesn't crash. BLink behaves the same, which doesn't surprise much.

To write something constructive: I need an idea how a working executable has to look for you, then maybe we can think about what an object file needs.
Ok let's start from scratch:

* the aout format supports 3 segments: text, data and bss. You may omit some but it's not possible to add more segments.
* the aout format also supports 'stabs' which aren't a segment but provide some important information to the linker. Information that is heavily used by common libraries as ixemul, noixemul, clib2, ...

How can support for chip/fast/far RAM be added?

Let's use the amiga hunk format, since all the old Amiga compilers supported that.

* the amiga hunk format supports plenty segments.

BUT, wait:

* there is no mapping in the amiga hunk format for e.g. constructors or managed arrays used to initialize stuff.

So I put it into DEBUG_HUNKs since my tests showed that

* the HUNK_DEBUG relocation is resolved during linking, no reloc ends in the executable.
* the information can be picked up by thelinker and the linker handles it.
* the programs do run.

Yes, I could change the type of that section to HUNK_DATA or HUNK_CODE, but that would not help: Other linkers would pick that up and add id to the program as data plus the user wonders why it's not working.

As long no such aout stabs are used (and without -g) no HUNK_DEBUGs are created and everything is fine, even with other linkers.

If aout stabs are used I'm fine with the fact that some linkers will complain/fail/whatever since the program would fail too.

The Amiga hunk format from 1990 or earlier had no support for PPC but it was ok to extend the format. And it wrote:

Code:
The basic format of a hunk is as follows:
· Hunk name block
· Relocatable block
· Relocation information block
· External symbol information block
· Symbol table block
· Debug block
· End block
So if you regard the HUNK_DEBUG as a relocatable block, everything is fine. Plus the OS loader does not complain.
And if some linker already supports aout and handles stabs the information can be easily extracted from the HUNK_DEBUG.

Last edited by bebbo; 27 December 2017 at 00:17.
bebbo is offline  
Old 27 December 2017, 19:23   #562
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,191
Quote:
Originally Posted by bebbo View Post
What is correct? The executables are running fine. Is that incorrect?
You didn't tell me that some unnamed linker removes these DEBUG-relocs. So there is just HUNK_DEBUG left, which LoadSeg() seems to ignore even when standing alone.

Quote:
Oh, the HUNK_DEBUG is ignored - simply skipped using it's length.
Ok, you were lucky.

Quote:
Let's use the amiga hunk format, since all the old Amiga compilers supported that.
Yes, but scratch "old".

Quote:
* there is no mapping in the amiga hunk format for e.g. constructors or managed arrays used to initialize stuff.
Unfortunately true. The usual workaround by Amiga compilers was to put some more work into the linker. The linker detects symbols starting for example with "__INIT" or "__EXIT" (also followed by a priority-digit, when needed) and allocates pointers to these symbols in an appropriate constructor/destructor array, which is simply attached to a data segment.


Quote:
* the HUNK_DEBUG relocation is resolved during linking, no reloc ends in the executable.
I haven't seen a linker which can do that. Did you modify an existing linker for that purpose?

Quote:
As long no such aout stabs are used (and without -g) no HUNK_DEBUGs are created and everything is fine, even with other linkers.
But constructors will need stabs. How many programs are there without constructors? I would guess even the clib uses them?

Quote:
The Amiga hunk format from 1990 or earlier had no support for PPC but it was ok to extend the format.
There was no other possibility to support the special relocation types needed for some PPC addressing modes. A new hunk in object files is better than abusing an existing one and confusing existing tools.

Quote:
So if you regard the HUNK_DEBUG as a relocatable block, everything is fine.
Sure. Just that it is no relocatable block. You listed it yourself as "Debug block" below the "Relocatable block".

I understand your problem. You have to map the a.out stabs somehow into hunk format, which is difficult, because symbol and debug hunks are always attached to a relocatable segment here.

Otherwise HUNK_DEBUG would be good, because you are free to define its contents. It would be better to include the relocations inside the HUNK_DEBUG, in a format of your choice, but it's still a strange construction then.

Assuming you are not willing to abandon the stab format, the best solution would be to create your own hunk. Make it HUNK_STAB (for example with 0x4f0 = HUNK_SYMBOL + 0x100). So only linkers which support it can read it, and others fail. But the linker must be able to resolve this hunk completely. Maybe it can be relocated, constructor tables added to data segments and the remaining symbols put into proper DEBUG hunks?
phx is offline  
Old 27 December 2017, 21:41   #563
bebbo
Registered User

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 307
Quote:
Originally Posted by phx View Post
...
Assuming you are not willing to abandon the stab format,
I want to use existing code as long as it works: gas creates the stabs and ld handles them.
Quote:
Originally Posted by phx View Post
the best solution would be to create your own hunk. Make it HUNK_STAB (for example with 0x4f0 = HUNK_SYMBOL + 0x100). So only linkers which support it can read it, and others fail. But the linker must be able to resolve this hunk completely. Maybe it can be relocated, constructor tables added to data segments and the remaining symbols put into proper DEBUG hunks?
Then I'd put more work into it but the result is the same:
"Only linkers which support it can read it, and others fail."

/shrug - where is the benefit?
bebbo is offline  
Old 28 December 2017, 07:29   #564
cla
dev

cla's Avatar
 
Join Date: Aug 2014
Location: Copenhagen
Age: 43
Posts: 63
Send a message via ICQ to cla
I have used gdb with gcc compiled code on Linux and Windows. Which debugger do you use in the above context?

Generally it is quiet hard to debug code without some kind of Integrated Development Environment, and without the possibility to inspect variables at runtime like gdb does, it really require some very specialized technical skills.

So I'm kind of curious.
cla is offline  
Old 28 December 2017, 10:48   #565
bebbo
Registered User

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 307
Quote:
Originally Posted by cla View Post
I have used gdb with gcc compiled code on Linux and Windows. Which debugger do you use in the above context?

Generally it is quiet hard to debug code without some kind of Integrated Development Environment, and without the possibility to inspect variables at runtime like gdb does, it really require some very specialized technical skills.

So I'm kind of curious.
I'm using Visual Studio (Windows)and Eclipse (Windows/Linux) for C/C++ development. To debug cygwin stuff with Visual Studio VisualGDB is useful.

But I have no working setup to debug remotely on an Amiga...
bebbo is offline  
Old 29 December 2017, 13:09   #566
bebbo
Registered User

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 307
FYI: Multilib is now enabled, building takes a tad longer but baserel applications linked against libgcc are less erraneous.
bebbo is offline  
Old 29 December 2017, 14:44   #567
emufan
Registered User
 
Join Date: Feb 2012
Location: #DrainTheSwamp
Posts: 4,546
Quote:
Originally Posted by bebbo View Post
You have to pass -fbaserel to the linker, since there are baserel files:
Code:
 m68k-amigaos-g++.exe -noixemul  lib/serv_s.o 3D.o AdjModel.o AdjPrims.o  Hash.o Heap.o Matrix.o ProxGrid.o Quadrics.o qemloss.o Decimate.o -o qemloss.p         -Llib/ lib/server.lib -lm -lstdc++ -lgcc -lamiga -fbaserel
Then linking succeeds.
ok. I will try this and report back.
emufan is offline  
Old 01 January 2018, 20:37   #568
arti
Registered User

 
Join Date: Jul 2008
Location: Poland
Posts: 497
Would it be possible to enable -flto ? It is in one program I am working on.
arti is offline  
Old 03 January 2018, 11:48   #569
arti
Registered User

 
Join Date: Jul 2008
Location: Poland
Posts: 497
Bebbo End of development?

I wanted to report an issue about buggy sprintf in libnix.

Noticed it in previous ports I've made.

Eg.
sprintf (buffer, "%s:%06d:", name, size);

returns NULL

but
snprintf (buffer, sizeof(buffer), "%s:%06d:", name, size);

works correctly.
arti is offline  
Old 03 January 2018, 12:40   #570
arti
Registered User

 
Join Date: Jul 2008
Location: Poland
Posts: 497
Also gcc 6 doesn't like operand '++='
Code:
*((long *)b)++ = 0;
error: lvalue required as left operand

Compiles fine with gcc 3.4.0.
arti is offline  
Old 03 January 2018, 16:12   #571
Marlon_
Amiga Programmer

Marlon_'s Avatar
 
Join Date: Mar 2016
Location: Sundsvall, Sweden
Age: 30
Posts: 483
Quote:
Originally Posted by arti View Post
Bebbo End of development?
I wouldn't think so.

Last edited by Marlon_; 04 January 2018 at 03:59.
Marlon_ is offline  
Old 03 January 2018, 18:56   #572
pipper
Registered User

 
Join Date: Jul 2017
Location: San Jose
Posts: 94
Would it make sense to give bebbo’s GCC6.2 toolchain it’s own subforum? I have a few comments and questions about it and I feel this thread is gettting too large, too unfocused already.
pipper is offline  
Old 03 January 2018, 18:58   #573
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 47
Posts: 442
Quote:
Originally Posted by arti View Post
Also gcc 6 doesn't like operand '++='
Code:
*((long *)b)++ = 0;
error: lvalue required as left operand

Compiles fine with gcc 3.4.0.
Yeah, well, linux doesn't like it either

Code:
gcc -c foo.c
foo.c: In function ‘foo’:
foo.c:3:15: error: lvalue required as increment operand
   *((long *)b)++ = 0;
               ^~
alex[1]@omen profile$ gcc --version
gcc (Ubuntu 7.2.0-8ubuntu3) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Maybe you meant to write:

Code:
*((long *)b++) = 0;
alkis is offline  
Old 03 January 2018, 19:00   #574
Marlon_
Amiga Programmer

Marlon_'s Avatar
 
Join Date: Mar 2016
Location: Sundsvall, Sweden
Age: 30
Posts: 483
Quote:
Originally Posted by pipper View Post
Would it make sense to give bebbo’s GCC6.2 toolchain it’s own subforum?
Sounds like a good idea. The ideal plan would be to get this compiler on par and beyond all previous versions of gcc toolchains for Amiga either way.
Marlon_ is offline  
Old 03 January 2018, 19:39   #575
arti
Registered User

 
Join Date: Jul 2008
Location: Poland
Posts: 497
Quote:
Originally Posted by alkis View Post
Yeah, well, linux doesn't like it either

Maybe you meant to write:

Code:
*((long *)b++) = 0;
Thanks I will try that.
Looks like gcc over 4.5 doesn't like it.

I am compiling libnix 3.0 with gcc6. Not my code.

My experience with this libnix version is good in terms of speed.
On my ports it was fastest comparing to clib2 and ixemul.

But it has bugs like sprintf mentioned above.
I have used snprintf code to fix it.

There are more bugs comparing to ixemul but I prefer to use libnix
because ixemul 63.1 needs fpu and additional library.


I hope bebbo includes libnix 3 in his toolchain and later we fix all it's bugs.
arti is offline  
Old 03 January 2018, 21:29   #576
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 47
Posts: 442
Obviously the code is buggy. The intention is to increment the pointer and not the dereferenced object (long).

Bebbo's gcc6 has a working libnix.
alkis is offline  
Old 03 January 2018, 21:44   #577
arti
Registered User

 
Join Date: Jul 2008
Location: Poland
Posts: 497
bebbo uses libnix 2.1 which doesn't use above code. Bug fixed with your suggestion.

I would prefer 3.0 to be dafault libnix as it provides more functions.
arti is offline  
Old 04 January 2018, 16:44   #578
AJCopland
Registered User

 
Join Date: Sep 2013
Location: Beeston, Nottinghamshire, UK
Posts: 110
Is there a reason that the GitHub project is archived?
AJCopland is offline  
Old 04 January 2018, 18:39   #579
Marlon_
Amiga Programmer

Marlon_'s Avatar
 
Join Date: Mar 2016
Location: Sundsvall, Sweden
Age: 30
Posts: 483
Quote:
Originally Posted by AJCopland View Post
Is there a reason that the GitHub project is archived?
None that has been stated as of yet. But on Bebbo's website it says this: "I am available for contract/remote work starting at 02.01.2018. Hire me!"

So maybe he just don't have time to work on it at the moment and needs a job to put food on his table.
Marlon_ is offline  
Old 08 January 2018, 11:25   #580
gregthecanuck
Registered User
 
Join Date: Mar 2017
Location: Vancouver, BC, Canada
Posts: 13
I tried emailing him a few days ago to make a donation for his great work so far. No reply yet.

Stefan: you don't want free money?? ;-)
gregthecanuck is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
New GCC based dev toolchain for AmigaOS 3.x cla Coders. Releases 8 24 December 2017 10:18
Issue with photon/xxxx WinUAE Toolchain arpz Coders. Asm / Hardware 2 26 September 2015 22:33
New 68k gcc toolchain arti Coders. C/C++ 17 31 July 2015 03:59
Hannibal's WinUAE Demo Toolchain 5 Bobic Amiga scene 1 23 July 2015 21:04
From gcc to vbcc. Cowcat Coders. General 9 06 June 2014 14:45

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 05:39.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.11059 seconds with 15 queries