@billyfish

So let's stick to 7.5.1 for the moment, and once we will deal with elf32-amiga.c and amiga-nat.c adaptation and it will work, we then can go further with no problems (and also have more experience).

Also probably 7.5.1 will be the best choice for start as later versions maybe need newer Binutils (because of BFD parts in that elf32-amigaos.c).

@kas1e

Great work! I agree, just sticking with something not too new is a good idea. Otherwise you'll need to solve 12^324 problems at once.

@sTix
Tried to traceback from where that strange terminal issue come (i.e. why it spawn for us "select: No such file or directory." and then in a row give "select: .").

I for sake of tests, port 6.3a version in the same way as I do for 7.5.1 (i.e. not adtools version, just fresh one, with the same kind of changes, same workarounds i do for 7.5.1): and this one didn't have that bug. Terminal works. I even tried to use the same readline library (just in case) from 6.3, but it's the same.

I added traces to main.c and top.c , and so far all passes fine in top.c's gdb_init(), init_main() and in main.c's captured_main() , that crap happens later.

@kas1e

I'm not at my amiga right now, so my dodgy memory might get this wrong. On linux, for the program that you're trying to debug, say it's called foobar, run

objdump -g foobar

and look for the part after "Contents of the .debug_info section:"

The DW_AT_name and DW_AT_comp_dir fields should be filled in for the DW_AT_compile_unit section and give the name of the source file and the directory that it is in respectively.

This is what gdb is looking for on linux at least.

Does the amiga program that you're running gdb with have these parts filled in? If so, we will at least know that the info is in the right place.

Tomorrow I should be able to get on my amiga and look properly rather than having to guess!

@billyfish

At this time i didnt tried to load anything: its just i run gdb as it and it says that cant open something and terminal start to act strange. I.e without loading anything. Loading of binary to debug surely will not works as elf32-amiga is empty stabs and no nat implementation added.

Maybe this 7.5.1 tried to load something automatically which 6.3 didnt, and tried to use non-implemented parts, dunno.

@billyfish
At least I find out the code triggered this: gdb/event-loop.c, function gdb_wait_for_event() and we have in loop that:



So that the "select" we have in a row when run gdb. Then i find out which call of that function exactly causes this, and this is in the same event-loop.c file, from the gdb_do_one_even(), there is the guilty part which was added after 6.3 (i.e. 6.3 do have the same function, but don't have that kind of code, so it's new):



The one in "case 1" is guilty. Once I comment out this gdb_wait_for_event(0), then the gdb terminal starts to behave correctly.




Is anyone can see anything wrong with that gdb_wait_for_event (0) call ?

@kas1e

Well found! Looking at the code, it looks like that gdb_select (), which is calling posix select () in posix_hdep.c, and that is returning -1. I'll add some debug messages to see what error is actually happening.

If the problem doesn't occur when we use gdb with a filename on the command line, then it won't affect how gdb is mostly used I guess.

@billyfish
Quote:

Yeah, it can be very well some os4 specific issue to the select() as well...

Quote:

We anyway need to understand wtf is happening so as to make a proper fix (even if it didn't break gdb usable in whole).

Btw, to make life easier to understand what we need to adapt from older versions is 2 files:

BFD/elf32-AmigaOS.c - that one already in repo, fully commented out at moment, with simple stubs at the top. This file is specific platform-dependent executable file support (in our case 32bit ELF). It's in BFD because BFD is an object file library, and used not only by GDB, but also by GAS, LD, and all those binary utils like objdump,readelf, etc, etc. Once we will adapt that file, then GDB will be able to load our debug-EFLs (but just load, i.e. GDB will be able to parse our ELF executables).

GDB/AmigaOS-nat.c - that one I didn't add to the repo at moment, but this one is must be adapted too, as this one is native-dependent code exactly for amigaos4 (for every system they have such files, like amd64-nat, arm-Linux-nat, etc, etc). As far as I see, that the file where all our magic happens: inserting breakpoints, creating amiga specific threads/tasks, fetching/store registers, etc, etc.

So once we deal with elf32-amigaos4.c i assume we will be able to just do "gdb test" , and inside of gdb do "list" to see source file. That will mean our elf32 support ok. Then we can concetrate on the amigaos4-nat (that will be for exactly debugging, disassembling, etc).


ps. checked the old adtools version, basically, elf32-amigaos4.c is in most parts straight copy of the elf32-ppc.c! So I assume we can follow the same way : copy over elf32-ppc.c, and replace only relevant parts as done in elf32-amigaos.c

@billyfish

Checked more close elf32-ppc.c and elf32-amigaos.c files in adtools repo, and they for real just almost straigh copy with minimal changes. So i adapt the same way to 7.5.1.

Now, once i run gdb, and tryig to load binary in, i have then :

Quote:

And now, the funny part : i tried to build adtools's version (our old 6.3 one) via newlib, and it cause the same issue ! I.e. works via clib2, but didn't via newlib and bring that "illegal seek" error.

I tried to just build 6.3 version as it (without other amiga patches) , and with adapted elf32-amiga it has exactly the same issue with newlib !

So, seems we have or bug in newlib's seek(), or it just some different implementation. But the fact that it works with clib2 , mean that it's not GDB code guilty imho.


@Salas00

Have you maybe any idea what can be wrong with newlib's seek() ?

@kas1e

So that is coming from exec_file_attach (), lin2 252 in gdb/exec.c, I'm guessing. It may not be a seek problem, but the code to check might be bfd_check_format_matches() in bfd/format.c.

Just to clarify, if you run

objdump -g helloworld

does it work?



It's me being slow, so apologies for this, but are you saying that you are getting that error for both clib2 and newlib on 7.5.1? And for 6.3,it works for clib2 but not newlib?


Hopefully be on my amiga in a couple of hours to check this too, but it looks like clib2 might be the way to go then.

@billyfish
Quote:

That what it output:



In meantime i will try to build 7.5.1 with adapted elf32-amiga.c over clib2, to see, if that "illegal seek" gone.


Quote:

"Illegal seek" error happens on 7.5.1 and on 6.3 if build with newlib. If build 6.3 with clib2, then no such error. Trying to build 7.5.1 now with clib2 to test.

I.e. it looks like clib2 builds not have error, but newlib ones have. But need to finish clib2 build of 7.5.1 to prove that.

@kas1e

Cheers ok that makes sense to my slow brain now So clib2 is hopefully the way to go. I found that to be the case with simplegit too when it comes to Posix compatibility.

Finally(!) on my amiga, and if I run gdb 7.5.1 on a simple hello_world program with


gdb helloworld


I get a grim reaper pointing at bfd_check_format_matches+ 0.210 (section 1 @0x230EC0) which ties in with my first guess of where the seek bug is that we need to fix.

@billyfish

Quote:

That all about our issue with "select" stuff. To avoid it for the moment just load gdb as it, and then "file HelloWorld" to have illegal seek :)

Also, I not sure if the clib2 version is the way to go, at the moment I have some troubles build the clib2 version: it builds mostly fine, but when about to builds GDB part itself start screaming about LONG/SHORT/FLOAT etc being redeclared (while for newlib there no such errors), tried to understand wtf.

If you want to try to build clib2 version, then:

Quote:

And after that you will have issues with FLOAT/LONG/SHORT being rediclared (happens with clib2 only, not with newlib), and i had to fix it by some hackish way currently: via commenting out in the clib2/include/unistd.h line 59, which is include of sys/select.h.

The add on the linking -lnet as well (for select() and ioctl() ), and then it links.

And, it kind of works. At least i can run gdb, then "file helloworld", it then bring skippable DSI, some pathes issues, and then load the file with my efl32-amiga. I even can list the source meaning that sections reads fine, see (press open in new tab for fullsize):

@billifish

Updated the repo with the new elf32-amiga.c which is a pure copy of elf32-ppc.c (as it was in our old version), with very minimal changes about names, etc. Also some ifndefs in the elf32-ppc.c itself to avoid "multiple definitions" of some functions (it can be dealing with compiler flags too, but less crap with configure/make files, the better).

I tested the same way by build 6.3 version (i.e. the same straight copy of elf32-ppc.c to elf32-amiga.c with the same minimal changes) and it reacts the same as expected, so chances that all fine is high.

Currently, it will work only if you build it with clib2 (because of illegal seek error), and with commented out gdb_wait_for_event (0) on line 439 in event_loop.c. By "will work" I mean you can load a file, it will be parsed, you can see source by "list" command, etc.

Through, I to be honest don't understand why it was done like this. Imho, there no need for that elf32-amiga.c file at all, can be just used original elf32-ppc.c, just with minimal ifdefs inside. But that, not a big deal, we can clean it all later if there will be needs.

Quote:

To clarify things a bit more, that what we have now:

1). "Illegal seek" error happens with newlib, but not with clib2, and that on 6.3 from adtools repo and with our 7.5.1 as well.

2). with both builds, newlib or clib2 of 7.5.1 we have on running "select ." calling in a row blocking terminal. To work around it we had to comment out in gdb/event-loop.c calling of gdb_wait_for_event (0);, on line 439.

So those 2 seem to be just separate issues.

Of course, for us will be better if we can use both newlib and clib2 builds because technically speaking, for GDB that should not matter if we use newlib or clib2, and that a good chance to find out a bug be it newlib or whatever.

In meantime will trying to adapt nat-amigaos.c, which seems _THAT_ file which for real mean amigaos4 work.


EDIT: traced a bit more that "illegal seek" issue, and that for sure come from bfd_seek() function: https://github.com/kas1e/gdb/blob/main/gdb-7.5.1/bfd/bfdio.c#L281 , i have printfs from there before we fail.

And it fails when called not from bfd_check_format_matches() for sure (i tried to comment out all of them inside of bfd_check_format_matches(), same error, so that not it).

Strangely it says before "not in executable format" which is in exec.c , but this one didn't call any bfd_seek..

@kas1e

Awesome!

I managed to get a clib2-ified build going avoiding some of the hacking. The config.h in libiberty was getting wrong values for clib2 which meant that it was trying to get alloca.h, process.h, etc. The __USE_CLIB2_TIMEVAL define removes the need to edit the sys/select.h file and I don't get the cast problems


1. ../configure --host=ppc-amigaos --target=ppc-amigaos --build=x86_64 --disable-nls --disable-werror --disable-sim CFLAGS="$CFLAGS -mcrt=clib2 -D__USE_CLIB2_TIMEVAL=1" LDFLAGS="$LDFLAGS -L/home/billy/Projects/amiga-gdb/ -lnet -lunix"

2. cd libiberty

3. patch < config.patch

4. cd ..

5. make

But my clib2 is causing me problems on the final linking of gdb with a missing getpgrp so I need to add that to the linking

However if I can't get the clib2 version to fully build, and given that it works on your set up, it's going to be that I'm missing something on my clib2 installation, I can still build the newlib version fine so I can work on both issues there hopefully.

config.patch:

@billyfish
Quote:

I have the same missing getpgrp in the inflow.c, so i just commente this call out in 2 places for have final linking.

That at least will give you ability to start it and load a file to see that elf32-amiga.c works. But IMHO we need to deal with that "seek" issue on newlib. It's just easer to build newlib version for now, and it's anyway better for our tests to have 2 builds.

At least we need to find our from where bsd_seek() call causing this issue, then add prinfs and build clib2 and newlib versions to see wtf happens. But seeing code of that bsd_seek() with all those SEEK_CUR and SEEK_SET i start to remember we have something of that sort issue when build MUI-VIM , so we had to build clib2 version of it, and not newlib one. Very possible that all related.

Quote:

Good catch ! Will be good to update repo so it can build newlb and clib2 versions. Just need to understand how to deal with that adding of undefs to alloca/process/malloc without patch , but from configure line (so to not have needs to patch things after configuring, and less steps in build process)

@kas1e

Quote:

Totally agree. We could have blocks like



what do you think?

in inflow.c that block at line 45 is what causes the problem, when building with clib2

so instead of



we could have




Ideally at the config stage we should just be able to put -DCLIB2=1 in the CFLAGS to switch from newlib to clib2. I did this in the makefiles for simplegit and libgit2 as it'#s a pain in neck/arse to get it building with the two different libs!

@billifish

Andreas remind that while clib2 proabaly didn't have own define, but newlib have, so to support both clib2 and newlib in the same code we don't need new flag, but:

Quote:

Also sadly when i provide configuring line of such kind:

Quote:

It adds -let and -lunix not at the end of linking line as expected, but at the beginning, before "-o gdb", so it didn't taken into account :(

@billyfish
@kas1e

I've started to investigate how to incorporate this into adtools so that gdb is built per default when gcc and binutils is built.