Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@transmeta.com>
To: "Kei Sakamoto" <sakamoto.kei@renesas.com>
Cc: "Daniel Jacobowitz" <drow@mvista.com>,
	<gdb-patches@sources.redhat.com>,
	newlib@sources.redhat.com
Subject: Re: [patch/testcase] gdb.asm/m32r.inc: fix compile error
Date: Wed, 06 Aug 2003 06:08:00 -0000	[thread overview]
Message-ID: <16176.39742.145428.442316@casey.transmeta.com> (raw)
In-Reply-To: <009b01c35bbc$dff15420$5169910a@KEI>

Kei Sakamoto writes:
 > > Two minor things:
 > >   - You accidentally sent a reversed diff.
 > >   - ChangeLog formatting.  It should be:
 > >
 > > 2003-08-04  Kei Sakamoto  <sakamoto.kei@renesas.com>
 > >
 > > * gdb.asm/m32r.inc: Add several missing symbols. Replace ld24
 > > with seth/add3.
 > 
 > Sorry about that.
 > 
 > > One less minor thing: no other port needs to declare symbols.  It looks
 > > like part of libc is being dragged in somehow on m32r; could you
 > > explain why the symbols are necessary?
 > 
 > asm-source is compiled with -nostartfiles. So gcc does not use libgloss.a.
 > But on m32r, somehow several system calls, _write, etc., are included
 > in it. So it is necessary to declare these symbols. On other architectures,
 > these system calls are included in libc.a, which is not removed
 > by -nostartfiles.
 > 
 > Unfortunately, I don't know why m32r's libgloss is different from others.
 > Should I modify libgloss and newlib rather than declare symbols in m32r.inc?

Imagine wanting to use libc in multiple environments,
the only difference between them is how the "board support package"
works.  There isn't necessarily one way that systems in which
a particular chip is placed implements system calls (for example).
Does one provide separate libc's for each?
Or does one factor out the board level issues from libc
and keep them separate.

This is how newlib+libgloss is intended to work.
It doesn't on some targets for various reasons.
For some older ports libgloss may not have existed at the time.

Thus, IMO, no you don't want to move libgloss into newlib.


  reply	other threads:[~2003-08-06  6:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-04  6:22 Kei Sakamoto
2003-08-05 18:02 ` Daniel Jacobowitz
2003-08-06  1:45   ` Kei Sakamoto
2003-08-06  6:08     ` Doug Evans [this message]
2003-08-06 13:04     ` Daniel Jacobowitz
2003-08-07  2:20       ` Kei Sakamoto
2003-08-07  4:06         ` Daniel Jacobowitz
2003-08-07  4:17   ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16176.39742.145428.442316@casey.transmeta.com \
    --to=dje@transmeta.com \
    --cc=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=newlib@sources.redhat.com \
    --cc=sakamoto.kei@renesas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox