I've started to investigate how to incorporate this into adtools so that gdb is built per default when gcc and binutils is built.
Good!
If you have time you may also try to check our 2 issues: why newlib has "illegal seek" when we load the file in, while clib2 did not that, and why we have the "select ." command in a terminal in a row blocking terminal. The more people work on real coding issues the better :)
The plan is to start with all the rest in binutils, it's sort of glued together with gdb so I think we need to do some work on the current patch set. After that I can have a look at amigaos-nat and co. It's not yet clear to me how this works but if we just do some random work here and there it will probably work out in the end
The plan is to start with all the rest in binutils, it's sort of glued together with gdb so I think we need to do some work on the current patch set. After that, I can have a look at amigaos-nat and co. It's not yet clear to me how this works but if we just do some random work here and there it will probably work out in the end
I not very much understand it too, but seems GDB has inside just a "copy" of the BFD library from Binutils. So we either can use one from Binutils, or, build always one coming with GDB itself (as we do now).
Downloading the original 8.3.1 source code of GDB shows that BFD directory is here. While downloading morphos' SDK, shows that they instead delete it from there, and use one from binutils. Probably reasons because they implement it one and for once, so all other programs (like objdump and co) will use it, so why not use ready on in GDB too.
@billyfish
Quote:
make LOADLIBES="$LOADLIBES -lunix -lnet"
Oh, I remember, for now, it's just we shouldn't use LDFLAGS for the libraries, but LIBS instead, will check if can deal with just from configure line, without adding anything to make command
At least if i add prinfs before all 3 bfd_seeks() in that fucntion, i have printfs before that one when it quite with "illegal seek". But, if i comment this one out, it still exit, and still with the same illegal seek :) We may need to prinfs values of abfd, and file_ptr on both newlib and clib2 builds, so we can see if values are differs much.
The only major difference between clib2 and newlib seek implementations that I can see is that clib2 allows out of bounds seeks by extending the file also if the file is opened as O_RDONLY, whereas newlib only auto extends for O_WRONLY and O_RDWR.
printf ("0 calling bfd seek with %s with pos %d and direction %d\n", abfd -> filename, (file_ptr) 0, SEEK_SET);
and
int
bfd_seek (bfd *abfd, file_ptr position, int direction)
{
int result;
file_ptr file_position;
/* For the time being, a BFD may not seek to it's end. The problem
is that we don't easily have a way to recognize the end of an
element in an archive. */
printf ("bfd_seek called with %s with pos %d and direction %d\n", abfd -> filename, position, direction);
BFD_ASSERT (direction == SEEK_SET || direction == SEEK_CUR);
if (direction == SEEK_CUR && position == 0)
return 0;
if (abfd->format != bfd_archive && abfd->my_archive == 0)
{
if (direction == SEEK_SET && (bfd_vma) position == abfd->where)
return 0;
}
else
{
/* We need something smarter to optimize access to archives.
Currently, anything inside an archive is read via the file
handle for the archive. Which means that a bfd_seek on one
component affects the `current position' in the archive, as
well as in any other component.
It might be sufficient to put a spike through the cache
abstraction, and look to the archive for the file position,
but I think we should try for something cleaner.
In the meantime, no optimization for archives. */
}
if (abfd->iovec)
{
result = abfd->iovec->bseek (abfd, file_position, direction);
printf ("1: seeking %s with pos %d and direction %d has result %d\n", abfd -> filename, file_position, direction, result);
}
else
{
printf ("2: iovec for %s is null\n", abfd -> filename);
result = -1;
}
if (result != 0)
{
int hold_errno = errno;
/* Force redetermination of `where' field. */
bfd_tell (abfd);
/* An EINVAL error probably means that the file offset was
absurd. */
if (hold_errno == EINVAL)
{
printf ("3: seeking %s EINVAL\n", abfd -> filename);
0 calling bfd seek with Workspace:/helloworld with pos 0 and direction 0
bfd seek called with Workspace:/helloworld with pos 0 and direction 0
BFD: BFD (GNU Binutils) 2.22.52.20120718 assertion fail ../../bfd/elf.c:241
bfd_seek called with Workspace:/helloworld with pos 0 and direction 12060
1: seeking Workspace:/helloworld with pos 0 and direction 12060 has result 0
4: seeking Workspace:/helloworld has error 29
returning Worksapce:/helloworld : -1
"Workspace:/helloworld": not in executable format: illegal seek
So the direction then being 12060 seems like where things go very wrong!
Unless some weird redefining is going on, direction should be 0, 1 or 2 for SEEK_SET, SEEK_CUR and SEEK_END. Even the GNU extensions only add values for 3 and 4. So somewhere direction is getting set strangely.
Have you checked what type file_ptr is. If it's 64-bit (long long) then you need to use %lld. If the low 32-bit of pos is printed as direction then that would explain where the 12060 is coming from.
(gdb) file helloworld
file helloworld
0 calling bfd seek with Workspace:/helloworld with pos 0 (8) and direction 0 (4)
bfd_seek called with Workspace:/helloworld with pos 0 (8) and direction 0 (4)
BFD: BFD (GNU Binutils) 2.22.52.20120718 assertion fail ../../bfd/elf.c:241
bfd_seek called with Workspace:/helloworld with pos 0 (8) and direction 0 (4)
1: seeking Workspace:/helloworld with pos 12060 and direction 0 has result -1
4: seeking Workspace:/helloworld has error 29
returning Workspace:/helloworld : -1
"Workspace:/helloworld": not in executable format: Illegal seek
(gdb)
The numbers in the brackets after the pos and direction are the sizeof values to make sure I don't get caught out with that again
So it's calculated the right position to scroll to for my executable but the subseqeunt seek to this position fails
Edited by billyfish on 2021/2/23 16:52:57 Edited by billyfish on 2021/2/23 17:11:45
(gdb) file helloworld
file helloworld
0 calling bfd seek with Workspace:/helloworld with pos 0 (8) and direction 0 (4)
bfd_seek called with Workspace:/helloworld with pos 0 (8) and direction 0 (4)
bfd_seek called with Workspace:/helloworld with pos 0 (8) and direction 0 (4)
cache_bseek f not null with Workspace:/helloworld with pos 12060 (8) and direction 0 (4)
using fseeko64
real_fseek returned -1 with Workspac:/helloworld with pos 12060 (8) and direction 0 (4)
1: seeking Workspace:/helloworld with pos 12060 and direction 0 has result 89
4: seeking Workspace:/helloworld has error 29
returning Workspace:/helloworld : 89
"Workspace:/helloworld": not in executable format: Illegal seek
(gdb)
4.Workspace:> gdb-newlib
GNU gdb (GDB) 7.5.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "ppc-amigaos".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) file helloworld
file helloworld
0 calling bfd seek with Workspace:/helloworld with pos 0 (8) and direction 0 (4)
bfd_seek called with Workspace:/helloworld with pos 0 (8) and direction 0 (4)
bfd_seek called with Workspace:/helloworld with pos 0 (8) and direction 0 (4)
cache_bseek f not null with Workspace:/helloworld with pos 12060 (8) and direction 0 (4)
using fseek
real_fseek returned 0 with Workspace:/helloworld with pos 12060 (8) and direction 0 (4)
1: seeking Workspace:/helloworld with pos 12060 and direction 0 has result 88
4: seeking Workspace:/helloworld has error 2
returning Workspace:/helloworld : 88
"Workspace:/helloworld": not in executable format: No such file or directory
(gdb)
Which is a slight improvement and hopefully by setting
etc., correctly across the entire project we may be getting there as I'm hoping the later failure is due to other parts of the io code still using the "o64" function calls.
Just simple adding to the gdb-build/bfd/config.h after configuring done, at the end those undefs you mention, and recompiling the whole thing, make it all works! No more illegal seek!
Now, we need to check, if on clib2 those defines enabled at all? Maybe not, and that why it works on clib2. Through, it still looks like newlib ones are guilty anyway, is it correct?
Probably now while we at least kind of understand issues with illegal seek, we need to understand wtf with another issue: why when we have gdb_wait_for_event (0); in event_loop(), we have that "select ." typing always in gdb terminal in the loop. After that, we will be at least at beginning of polish things and then concentrate on that "amigaos-nat" part. Once it will work on peg2/x1000/etc where the old one works, we then can concentrate on x5000 and we have a new version :)
That kind of explains why it works on clib2: because on clib2 it didn't use those x64 functions, while on newlib we have them, and tried to use them, and fail. Meaning it's not clib2 there better, it's just clib2 didn't have those functions, while newlib have (through, they seem to have issues?) At least FTELLO64 and FSEEKO64?
@billyfish That will help for sure. Can you made such a small test case ? (i just not very well understand issue, so can't myself). If Frederik in interest to deal with in newlib testcase will help.
We for time being can of course easy workaround it in the repo while (and if) fixed newlib will be avail.
For now tryng to debug that gdb_wait_for_event (0); in event_loop() issue. Strange why it call "select .". "Select" is probabaly short-named command for selecting a frame ?
For now tryng to debug that gdb_wait_for_event (0); in event_loop() issue. Strange why it call "select .". "Select" is probabaly short-named command for selecting a frame ?
It's POSIX I/O lingo
Not sure if there are any limitations in the Amiga implementation, if so, you also have the option of using poll().
just in bfd's sysdep.h, so all will automatically be taken exactly for aos4/newlib only. We can keep this one until fixed newlib will be out, but for time being workaround is good enough for sure, not worse than how it was with clib2 builds before.
not sure if it possible to "configure" the gdb line to say "disable ftello64/fseeko64"? If not, the way how I did it can be kept IMHO? (just one single change, not a big deal).
@all And I tested dwarf2/4 support: our old GDB indeed only supports dwarw2, while 7.5.1 can load up dwarf 4 bins! See:
(open in new tab for full size)
There I show that binary compiled with dwarf4 support, then tried to load it up with old-current gdb: says sorry, 4 not support, and then load it up with our new v7.5.1: it works. So, once we have done with nat-amigaos.c, we at least will have one major feature right away: working dwarf4 support. Then if x5000 support will be added it will be something at last (after 10 years ?)
1). added original and old amigaos-nat.c from old version of our gdb from adtools on sourceforge. 2). changed gdb/config/amigaos.mh, so amigaos-nat.c will be compiled and linked now. 3). get rid of most compilation errors in it (see latest commits history). There were just one DOS difference, then bunch of pure-rename functions in the GDB itself since v.6.3 times, and disabled sobjs for now (first we need to make it works at all).
Now, what is left is 2 undefs on compiling stage
PC_REGNUM and current_regcache
"PC_REGNUM" it seems now "gdbarch_pc_regnum (gdbarch)", or maybe "PPC_MQ_REGNUM", that need to be checked with context. And "current_regcache" in our case it seems now just "regcache". Through, both of them give me "undefined" so probably some gdb includes need to be added or something. Seems those ones need to be changed in the function's arguments and filled in some other functions.
Cheers Roman, great work again. current_regcache looks like an easy fix it's just setting it from get_current_regcache (). I'm working my way through that and the warnings for amigaos-nat.c and will make a pull request for you when I'm done.
BREAKPOINT_FROM_PC (), amigaos_find_lib () and amigaos_add_lib () are currently undefined, are they defined in the 6.3 branch anywhere?
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
