Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #100610

Re: Pine 64

Show all headers | View raw

On 28/12/16 22:55, jacobnavia wrote:
> Le 28/12/2016 à 21:53, David Brown a écrit :
>> And Jacob was talking about compiling C on it, and even compiling his C
>> compiler on it, before we got side-tracked.
> 

This is way off topic, and I don't know all the details, but I can try
to offer you a little help.  After that, you might find more direct help
on the binutils or gcc mailing lists.

> Yeah, I got to the link phase. I compiled lcc wit gcc, and that compiler
> was used to compile the same code again producing (at last) a bloated
> executable, full of bad code, but an executable nevertheless.

If you compiled without optimisation and/or with debug information,
executables will be big.  Debugging information can be several times as
big as the code itself.

> 
> Normal for the first iteration. This process is called boot strapping,
> and it is a PITA, as it is commonly called...
> 
> The fact that all the code was translated with a correct assembler
> syntax was a big step. Now, there is a big problem with the debug info.
> 
> If I link with the debug info, the linker tells me
> 
> stabs index error.
> 
> And doesn't produce an executable.

Stabs has been out of date for about a decade on most platforms that use
elf format executables (such as Linux).  I believe it is still used on
BSD (which is notoriously conservative - for good and for bad), for some
other "real" Unix systems, and sometimes with coff format executables.

For Linux, you should generate elf files with dwarf debugging.  Dwarf is
a bit more complex than stabs, but has a lot more features and
flexibility, and is better documented.

> 
> Of course, I would be rather keenly interested in knowing where in the
> 1.5 MB of code full of stab statements the error could be???

Ask the linker to generate a map file.  And learn about objdump.

(I don't mean to be rude here - it's just that once you have these
pointers, it is easy to find tutorials and references on the net that
are a lot more useful than anything I could write in this newsgroup.)

> 
> But the linker will not tell me, why should it?
> 
> If you are the developer of the linker and you know only gcc is around
> why bother specifying the module and line number or index of the stab or
> whatever. A sensible error message is too much asking here.

The linker is from a different project from gcc - it is part of the
binutils project that also contains the assembler and the librarian
"ar", and some other utilities.  The gcc developers and the binutils
developers talk to each other, and are under the same GNU umbrella, but
they are not directly connected.  People use the gnu linker with other
compilers and other languages, they also use gcc along with different
linkers and assemblers.


> 
> Another problem (solved this one) was the c library. I could not compile
> the headers of gcc, full of strange stuff with __attribute__ whatever.
> But making appropiate #defines solved that problem and I could link,
> albeit without the debug info.

The "strange" __attribute__ "stuff" is all documented in gcc's manual,
to at least some extent.  And I don't think you mean "the headers of
gcc" - I think you mean "the Linux headers" and/or "the glibc headers".
 Both of these are projects that are independent of gcc, but make use of
many of gcc's extensions.

> 
> Problem is, I am generating stabs and gcc has changed to dwarf. Do they
> correctly support stabs any more?

If you want to make code suitable for Linux, generate elf files with dwarf.

> 
> If that is the case I would have to rewrite the debugger and use my own
> format. I remember that I had a debugger using the ptrace interface back
> then.
> 

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-27 23:44 +0100
  Re: Pine 64 raltbos@xs4all.nl (Richard Bos) - 2016-12-27 22:54 +0000
    Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-28 00:41 +0100
      Re: Pine 64 raltbos@xs4all.nl (Richard Bos) - 2016-12-28 12:14 +0000
    Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-28 13:39 +0100
      Re: Pine 64 raltbos@xs4all.nl (Richard Bos) - 2016-12-28 12:45 +0000
        Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-28 14:02 +0100
          Re: Pine 64 Keith Thompson <kst-u@mib.org> - 2016-12-28 10:11 -0800
            Re: Pine 64 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-28 10:50 -0800
            Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-28 22:55 +0100
              Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-29 12:21 +0100
                Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-29 21:38 +0100
                Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-30 10:10 +0100
            Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-28 21:53 +0100
            Re: Pine 64 raltbos@xs4all.nl (Richard Bos) - 2016-12-28 19:54 +0000
  Re: Pine 64 Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-27 18:03 -0500
    Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-28 00:36 +0100
      Re: Pine 64 Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-27 18:44 -0500
        Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-28 00:54 +0100
  Re: Pine 64 Noob <root@127.0.0.1> - 2016-12-28 11:27 +0100
    Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-28 12:10 +0100
      Re: Pine 64 Noob <root@127.0.0.1> - 2016-12-28 12:59 +0100
  Re: Pine 64 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-28 10:10 -0800
    Re: Pine 64 supercat@casperkitty.com - 2016-12-29 08:30 -0800
    Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-29 13:22 +0100
      Re: Pine 64 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 07:47 -0800
        Re: Pine 64 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 17:03 +0000
      Re: Pine 64 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 04:50 -0800
        Re: Pine 64 Reinhardt Behm <rbehm@hushmail.com> - 2016-12-29 21:25 +0800
      Re: Pine 64 Keith Thompson <kst-u@mib.org> - 2016-12-29 09:28 -0800
      Re: Pine 64 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 14:22 +0000
    Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-29 13:28 +0100
    Re: Pine 64 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-28 14:12 -0800
      Re: Pine 64 BartC <bc@freeuk.com> - 2016-12-28 22:23 +0000
      Re: Pine 64 Gareth Owen <gwowen@gmail.com> - 2016-12-29 18:43 +0000
    Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-28 21:59 +0100
    Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-28 23:43 +0100
    Re: Pine 64 jt@toerring.de (Jens Thoms Toerring) - 2016-12-28 22:56 +0000
      Re: Pine 64 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-28 16:00 -0800
        Re: A programming language called 'B64' Noob <root@127.0.0.1> - 2016-12-30 16:08 +0100

csiph-web