Re: CVS commit: src/lib/csu

2018-12-28 Thread Rin Okuyama

Thanks! GCC on m68k gets working again.

rin

On 2018/12/29 3:17, Christos Zoulas wrote:

Module Name:src
Committed By:   christos
Date:   Fri Dec 28 18:17:11 UTC 2018

Modified Files:
src/lib/csu/arch/aarch64: Makefile.inc
src/lib/csu/arch/arm: Makefile.inc
src/lib/csu/arch/earm: Makefile.inc
src/lib/csu/arch/or1k: Makefile.inc
src/lib/csu/arch/riscv: Makefile.inc
src/lib/csu/common: Makefile.inc crt0-common.c crtbegin.c

Log Message:
Undo previous; breaks macppc/m68k (at least)


To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 src/lib/csu/arch/aarch64/Makefile.inc
cvs rdiff -u -r1.8 -r1.9 src/lib/csu/arch/arm/Makefile.inc
cvs rdiff -u -r1.4 -r1.5 src/lib/csu/arch/earm/Makefile.inc
cvs rdiff -u -r1.2 -r1.3 src/lib/csu/arch/or1k/Makefile.inc
cvs rdiff -u -r1.2 -r1.3 src/lib/csu/arch/riscv/Makefile.inc
cvs rdiff -u -r1.34 -r1.35 src/lib/csu/common/Makefile.inc
cvs rdiff -u -r1.21 -r1.22 src/lib/csu/common/crt0-common.c
cvs rdiff -u -r1.16 -r1.17 src/lib/csu/common/crtbegin.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


Re: CVS commit: src/lib/csu/common

2018-07-13 Thread maya
On Fri, Jul 13, 2018 at 04:48:32PM +0700, Robert Elz wrote:
> Date:Fri, 13 Jul 2018 09:38:02 +
> From:m...@netbsd.org
> Message-ID:  <20180713093802.ga20...@homeworld.netbsd.org>
> 
>   | ack. we should probably leave the build broken, anyone who tries out the
>   | resulting netbsd might have to spend some time figuring out how to boot
>   | without /sbin/init (it's boot -a and then pick /rescue/init).
> 
> You may have seen from my more recent message to current-users
> that I encountered that problem
> 
> However I assumed that if init was going to core dump, most likely
> so would everything else, and init was just the one that hit the problem
> first.Are you saying that is wrong, and it is only init that is broken?
> 
> I cannot test at the minute, I generally do "update" builds, so I have
> started a "destroy and restart" build instead - so my test filesystem is
> empty right now.
> 
> Once that finishes (more hours than it should take, as I don't use -j
> as I don't really want to swamp the build system, which has other real
> work to do, with my playing around...) I will test again.
> 
> If no other fix (or likely fix) has appeared in the meantime, I will see if
> I can work out how to cleanly revert joerg's changes (locally here) and
> see if that helps.


No, everything dumps core. Fortunately I updated with a terminal open
running as root, so I could PATH=/rescue ftp base.tgz, tar.


Re: CVS commit: src/lib/csu/common

2018-07-13 Thread Robert Elz
Date:Fri, 13 Jul 2018 09:38:02 +
From:m...@netbsd.org
Message-ID:  <20180713093802.ga20...@homeworld.netbsd.org>

  | ack. we should probably leave the build broken, anyone who tries out the
  | resulting netbsd might have to spend some time figuring out how to boot
  | without /sbin/init (it's boot -a and then pick /rescue/init).

You may have seen from my more recent message to current-users
that I encountered that problem

However I assumed that if init was going to core dump, most likely
so would everything else, and init was just the one that hit the problem
first.Are you saying that is wrong, and it is only init that is broken?

I cannot test at the minute, I generally do "update" builds, so I have
started a "destroy and restart" build instead - so my test filesystem is
empty right now.

Once that finishes (more hours than it should take, as I don't use -j
as I don't really want to swamp the build system, which has other real
work to do, with my playing around...) I will test again.

If no other fix (or likely fix) has appeared in the meantime, I will see if
I can work out how to cleanly revert joerg's changes (locally here) and
see if that helps.

kre



re: CVS commit: src/lib/csu/common

2016-06-02 Thread matthew green
"Joerg Sonnenberger" writes:
> Module Name:  src
> Committed By: joerg
> Date: Wed Jun  1 21:24:55 UTC 2016
> 
> Modified Files:
>   src/lib/csu/common: Makefile.inc
> 
> Log Message:
> Revert -O1 hack for GCC 5.3, replaced by workaround in the code.

please update doc/HACKS.  thanks!


.mrg.


Re: CVS commit: src/lib/csu/common

2013-11-17 Thread Martin Husemann
On Sun, Nov 17, 2013 at 08:40:51AM +0900, Takeshi Nakayama wrote:
 I think proper fix is to use CSU_MACHINE_ARCH instead of
 MACHINE_ARCH.

Indeed, thanks!

Martin


re: CVS commit: src/lib/csu

2013-09-10 Thread matthew green

 Module Name:  src
 Committed By: matt
 Date: Tue Sep 10 16:45:33 UTC 2013
 
 Modified Files:
   src/lib/csu: Makefile
   src/lib/csu/arch/earm: Makefile.inc
   src/lib/csu/common: Makefile.inc sysident.S sysident_assym.cf
 
 Log Message:
 Add support for a NetBSD MARCH elf note to record the MACHINE_ARCH for
 which a program was compiled.

please update this doc:

   http://www.netbsd.org/docs/kernel/elf-notes.html

and perhaps remove the link to cgd while you're at it ;)

thanks.


.mrg.


re: CVS commit: src/lib/csu/common

2013-06-27 Thread matthew green

 Module Name:  src
 Committed By: matt
 Date: Thu Jun 27 03:37:21 UTC 2013
 
 Modified Files:
   src/lib/csu/common: Makefile.inc
 
 Log Message:
 Add -fPIC to compile of crtbeginS.o

what is this for?  crtbeginS.o is for static binaries isn't it?


.mrg.


Re: CVS commit: src/lib/csu/common

2013-06-27 Thread Matt Thomas

On Jun 27, 2013, at 7:28 AM, matthew green m...@eterna.com.au wrote:

 
 Module Name: src
 Committed By:matt
 Date:Thu Jun 27 03:37:21 UTC 2013
 
 Modified Files:
  src/lib/csu/common: Makefile.inc
 
 Log Message:
 Add -fPIC to compile of crtbeginS.o
 
 what is this for?  crtbeginS.o is for static binaries isn't it?

crtbegin.o is for static
crtbeginS.o is for shared


Re: CVS commit: src/lib/csu/common

2013-06-27 Thread Joerg Sonnenberger
On Thu, Jun 27, 2013 at 08:03:06AM -0700, Matt Thomas wrote:
 
 On Jun 27, 2013, at 7:28 AM, matthew green m...@eterna.com.au wrote:
 
  
  Module Name:   src
  Committed By:  matt
  Date:  Thu Jun 27 03:37:21 UTC 2013
  
  Modified Files:
 src/lib/csu/common: Makefile.inc
  
  Log Message:
  Add -fPIC to compile of crtbeginS.o
  
  what is this for?  crtbeginS.o is for static binaries isn't it?
 
 crtbegin.o is for static
 crtbeginS.o is for shared

Actually, it is crtbegin.o for the main binary, crtbeginS.o for shared
objects and crtbeginT.o for static binaries. Making crtbegin.o PIC is
useful for PIE.

Joerg


Re: CVS commit: src/lib/csu/common

2013-06-27 Thread Matt Thomas

On Jun 27, 2013, at 8:33 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote:

 On Thu, Jun 27, 2013 at 08:03:06AM -0700, Matt Thomas wrote:
 
 On Jun 27, 2013, at 7:28 AM, matthew green m...@eterna.com.au wrote:
 
 
 Module Name:   src
 Committed By:  matt
 Date:  Thu Jun 27 03:37:21 UTC 2013
 
 Modified Files:
src/lib/csu/common: Makefile.inc
 
 Log Message:
 Add -fPIC to compile of crtbeginS.o
 
 what is this for?  crtbeginS.o is for static binaries isn't it?
 
 crtbegin.o is for static
 crtbeginS.o is for shared
 
 Actually, it is crtbegin.o for the main binary, crtbeginS.o for shared
 objects and crtbeginT.o for static binaries. Making crtbegin.o PIC is
 useful for PIE.


We don't build crtbeginT.o any more.

Re: CVS commit: src/lib/csu/common

2013-06-27 Thread Joerg Sonnenberger
On Thu, Jun 27, 2013 at 09:54:33AM -0700, Matt Thomas wrote:
 
 On Jun 27, 2013, at 8:33 AM, Joerg Sonnenberger jo...@britannica.bec.de 
 wrote:
 
  On Thu, Jun 27, 2013 at 08:03:06AM -0700, Matt Thomas wrote:
  
  On Jun 27, 2013, at 7:28 AM, matthew green m...@eterna.com.au wrote:
  
  
  Module Name: src
  Committed By:matt
  Date:Thu Jun 27 03:37:21 UTC 2013
  
  Modified Files:
   src/lib/csu/common: Makefile.inc
  
  Log Message:
  Add -fPIC to compile of crtbeginS.o
  
  what is this for?  crtbeginS.o is for static binaries isn't it?
  
  crtbegin.o is for static
  crtbeginS.o is for shared
  
  Actually, it is crtbegin.o for the main binary, crtbeginS.o for shared
  objects and crtbeginT.o for static binaries. Making crtbegin.o PIC is
  useful for PIE.
 
 
 We don't build crtbeginT.o any more.

Correct, so crtbegin.o should also be PIC.

Joerg


Re: CVS commit: src/lib/csu

2011-02-06 Thread David Holland
On Mon, Jan 31, 2011 at 10:45:34PM +, David Holland wrote:
  However, as I recall it ought to work ok to do
  
  Var_Set(.PARSEDIR, $(.CURDIR), VAR_GLOBAL, 0);
  
  instead.
  
  However, this still isn't a correct fix as it doesn't take care of the
  case when e.g. including ../Makefile.inc.
  
  Furthermore, before going around hacking make, please come up with an
  isolated test case where make does the wrong thing. So far I can't
  find one.

So for the record the problem is caused when (1) neither MAKEOBJDIR
nor MAKEOBJDIRPREFIX is set; (2) no matching objdir exists at make
startup; (3) after that point OBJDIR is explicitly assigned to
something that *does* exist; (4) at that time make chdirs but does not
update .PARSEDIR.

Making .PARSEDIR always absolute should fix this problem, but in the
general case requires realpath(). However, I'm guessing that .PARSEDIR
may not be the only path variable affected -- ISTM that the right
thing to do is to track down why assigning OBJDIR after startup does
not update all the same things that assigning it during startup does,
and fix that. (And, preferably, fix it so the code is shared and it
won't break again.)

-- 
David A. Holland
dholl...@netbsd.org


Re: CVS commit: src/lib/csu

2011-02-06 Thread David Laight
On Sun, Feb 06, 2011 at 07:46:23PM +, David Holland wrote:
 Making .PARSEDIR always absolute should fix this problem, but in the
 general case requires realpath().

It will also give problems to anyone using bmake under cygwin to
run windows binaries.

David

-- 
David Laight: da...@l8s.co.uk


Re: CVS commit: src/lib/csu

2011-02-06 Thread Simon J. Gerraty
Making .PARSEDIR always absolute should fix this problem, but in the
general case requires realpath(). 

Yes.  Though it is worth noting that setting .PARSEDIR to .CURDIR when
the makefile path contains no '/' may be sufficient for correct
operation.

However, I'm guessing that .PARSEDIR
may not be the only path variable affected -- ISTM that the right
thing to do is to track down why assigning OBJDIR after startup does
not update all the same things that assigning it during startup does,

That would boil down to re-running main() and re-reading makefiles etc.
A lot of overhead.

A possibly simpler solution might be to shift the default objdir logic
until after sys.mk has been read, and invoke it only if cwd has not
changed.

There's still no guarantee that you won't break half the world though
;-)

--sjg


Re: CVS commit: src/lib/csu

2011-02-01 Thread Matthias Drochner

jo...@britannica.bec.de said:
 The attached patch seems to sort this out.

Yes, thanks, this works.

best regards
Matthias





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt




Re: CVS commit: src/lib/csu

2011-01-31 Thread Joerg Sonnenberger
On Mon, Jan 31, 2011 at 07:32:50PM +0100, Matthias Drochner wrote:
 
 m.droch...@fz-juelich.de said:
  $ make -V .OBJDIR
  [...]/src/lib/csu/obj.zelz27
 
 And as a data point, to show what's going wrong:
 $ make -V COMMON_DIR
 ./common
 
 That should be ../common, or better an absolute path.

$ ~/work/NetBSD/obj/clang-base/tools/bin/nbmake-amd64 -V COMMON_DIR
/home/joerg/work/NetBSD/trees/clang-base/src/lib/csu/common

$ ~/work/NetBSD/obj/clang-base/tools/bin/nbmake-amd64 -V .OBJDIR
/home/joerg/work/NetBSD/obj/clang-base/amd64/lib/csu

That's exactly what I am getting. So what exactly are your build
settings?

Joerg


Re: CVS commit: src/lib/csu

2011-01-31 Thread Matthias Drochner

jo...@britannica.bec.de said:
 $ ~/work/NetBSD/obj/clang-base/tools/bin/nbmake-amd64 -V .OBJDIR
 /home/joerg/work/NetBSD/obj/clang-base/amd64/lib/csu

This shows that you are not using an .OBJDIR, in the sense that it is
different from .CURDIR. See the make(1) manpage.

There are various rules which use this in mk/bsd.obj.mk. I'm
setting BUILDID and BSDOBJDIR in my /etc/mk.conf.

best regards
Matthias





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt




Re: CVS commit: src/lib/csu

2011-01-31 Thread Joerg Sonnenberger
On Mon, Jan 31, 2011 at 08:42:59PM +0100, Matthias Drochner wrote:
 
 jo...@britannica.bec.de said:
  $ ~/work/NetBSD/obj/clang-base/tools/bin/nbmake-amd64 -V .OBJDIR
  /home/joerg/work/NetBSD/obj/clang-base/amd64/lib/csu
 
 This shows that you are not using an .OBJDIR, in the sense that it is
 different from .CURDIR. See the make(1) manpage.
 
 There are various rules which use this in mk/bsd.obj.mk. I'm
 setting BUILDID and BSDOBJDIR in my /etc/mk.conf.

I can comment out the MAKEOBJDIR assignment in nbmake-amd64 and it still
works fine. BSDOBJDIR doesn't seem to do anything. BUILDID breaks this.
I have no idea why those variables even exist, the code in bsd.own.mk is
messy at best and I don't think it justifies the changes to the
Makefiles. As such, please either kill BUILDID or find a proper fix and
backout this change.

Joerg


Re: CVS commit: src/lib/csu

2011-01-31 Thread Matthias Drochner

jo...@britannica.bec.de said:
 BSDOBJDIR doesn't seem to do anything. BUILDID breaks this. I have no
 idea why those variables even exist, the code in bsd.own.mk is messy
 at best

I agree that the code is messy, but at least BUILDID serves a useful
purpose: I can use the same source tree from different machines
(NFS mounted) with different directory layouts.
This has always worked, for as long as I've been using NetBSD.

It seems that the PARSEDIR feature is broken. Can't tell whether
make(1) or the mess in share/mk is to blame, but this should
be solved before deploying it in the source tree.

best regards
Matthias





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt




Re: CVS commit: src/lib/csu

2011-01-31 Thread Joerg Sonnenberger
On Mon, Jan 31, 2011 at 09:54:03PM +0100, Joerg Sonnenberger wrote:
 On Mon, Jan 31, 2011 at 08:42:59PM +0100, Matthias Drochner wrote:
  
  jo...@britannica.bec.de said:
   $ ~/work/NetBSD/obj/clang-base/tools/bin/nbmake-amd64 -V .OBJDIR
   /home/joerg/work/NetBSD/obj/clang-base/amd64/lib/csu
  
  This shows that you are not using an .OBJDIR, in the sense that it is
  different from .CURDIR. See the make(1) manpage.
  
  There are various rules which use this in mk/bsd.obj.mk. I'm
  setting BUILDID and BSDOBJDIR in my /etc/mk.conf.
 
 I can comment out the MAKEOBJDIR assignment in nbmake-amd64 and it still
 works fine. BSDOBJDIR doesn't seem to do anything. BUILDID breaks this.
 I have no idea why those variables even exist, the code in bsd.own.mk is
 messy at best and I don't think it justifies the changes to the
 Makefiles. As such, please either kill BUILDID or find a proper fix and
 backout this change.

The attached patch seems to sort this out.

Joerg
Index: src/usr.bin/make/main.c
===
--- src/usr.bin/make/main.c
+++ src/usr.bin/make/main.c
@@ -179,11 +179,11 @@
 static void		MainParseArgs(int, char **);
 static int		ReadMakefile(const void *, const void *);
 static void		usage(void);
 
 static Boolean		ignorePWD;	/* if we use -C, PWD is meaningless */
-static char curdir[MAXPATHLEN + 1];	/* startup directory */
+char curdir[MAXPATHLEN + 1];	/* startup directory */
 static char objdir[MAXPATHLEN + 1];	/* where we chdir'ed to */
 char *progname;/* the program name */
 char *makeDependfile;
 pid_t myPid;
 

Index: src/usr.bin/make/parse.c
===
--- src/usr.bin/make/parse.c
+++ src/usr.bin/make/parse.c
@@ -2206,11 +2206,12 @@
 char *dirname;
 int len;
 
 slash = strrchr(filename, '/');
 if (slash == NULL) {
-	Var_Set(.PARSEDIR, ., VAR_GLOBAL, 0);
+	extern char curdir[];
+	Var_Set(.PARSEDIR, curdir, VAR_GLOBAL, 0);
 	Var_Set(.PARSEFILE, filename, VAR_GLOBAL, 0);
 } else {
 	len = slash - filename;
 	dirname = bmake_malloc(len + 1);
 	memcpy(dirname, filename, len);



Re: CVS commit: src/lib/csu

2011-01-31 Thread David Holland
On Mon, Jan 31, 2011 at 11:05:23PM +0100, Joerg Sonnenberger wrote:
  -static char curdir[MAXPATHLEN + 1]; /* startup directory */
  +char curdir[MAXPATHLEN + 1];/* startup directory */
[...]
  -Var_Set(.PARSEDIR, ., VAR_GLOBAL, 0);
  +extern char curdir[];
  +Var_Set(.PARSEDIR, curdir, VAR_GLOBAL, 0);

Please don't make messes like that; if you really need to extern it
put it in one of the header files.

However, as I recall it ought to work ok to do

Var_Set(.PARSEDIR, $(.CURDIR), VAR_GLOBAL, 0);

instead.

However, this still isn't a correct fix as it doesn't take care of the
case when e.g. including ../Makefile.inc.

-- 
David A. Holland
dholl...@netbsd.org


Re: CVS commit: src/lib/csu

2011-01-31 Thread David Holland
On Mon, Jan 31, 2011 at 10:34:25PM +, David Holland wrote:
  -static char curdir[MAXPATHLEN + 1];/* startup directory */
  +char curdir[MAXPATHLEN + 1];   /* startup directory */
[...]
  -   Var_Set(.PARSEDIR, ., VAR_GLOBAL, 0);
  +   extern char curdir[];
  +   Var_Set(.PARSEDIR, curdir, VAR_GLOBAL, 0);
  
  Please don't make messes like that; if you really need to extern it
  put it in one of the header files.
  
  However, as I recall it ought to work ok to do
  
  Var_Set(.PARSEDIR, $(.CURDIR), VAR_GLOBAL, 0);
  
  instead.
  
  However, this still isn't a correct fix as it doesn't take care of the
  case when e.g. including ../Makefile.inc.

Furthermore, before going around hacking make, please come up with an
isolated test case where make does the wrong thing. So far I can't
find one.

-- 
David A. Holland
dholl...@netbsd.org


Re: CVS commit: src/lib/csu

2011-01-31 Thread Simon J. Gerraty
 I can comment out the MAKEOBJDIR assignment in nbmake-amd64 and it still
 works fine. BSDOBJDIR doesn't seem to do anything. BUILDID breaks this.
 I have no idea why those variables even exist, the code in bsd.own.mk is
 messy at best and I don't think it justifies the changes to the
 Makefiles. As such, please either kill BUILDID or find a proper fix and
 backout this change.

FWIW I think I last used BSDOBJDIR etc 10+ years ago.
I tend to use something like:

MAKEOBJDIR='${.CURDIR:S,${SRCTOP},${OBJTOP},}'

The attached patch seems to sort this out.

I didn't follow the conversation, how is this patch relevant to BUILDID?

Index: src/usr.bin/make/parse.c
===
--- src/usr.bin/make/parse.c
+++ src/usr.bin/make/parse.c
@@ -2206,11 +2206,12 @@
 char *dirname;
 int len;
 
 slash = strrchr(filename, '/');
 if (slash == NULL) {
-  Var_Set(.PARSEDIR, ., VAR_GLOBAL, 0);
+  extern char curdir[];

I thought scoped externs like this were frowned on?

+  Var_Set(.PARSEDIR, curdir, VAR_GLOBAL, 0);
   Var_Set(.PARSEFILE, filename, VAR_GLOBAL, 0);


Re: CVS commit: src/lib/csu

2011-01-31 Thread Joerg Sonnenberger
On Mon, Jan 31, 2011 at 04:07:43PM -0800, Simon J. Gerraty wrote:
 I didn't follow the conversation, how is this patch relevant to BUILDID?

Some of the redefinition magic involved with BUILDID results in
.PARSEDIR as ., not a full path. This only happens if none of the
usual MAKEOBJDIR* variables is present in the environment.

 Index: src/usr.bin/make/parse.c
 ===
 --- src/usr.bin/make/parse.c
 +++ src/usr.bin/make/parse.c
 @@ -2206,11 +2206,12 @@
  char *dirname;
  int len;
  
  slash = strrchr(filename, '/');
  if (slash == NULL) {
 -Var_Set(.PARSEDIR, ., VAR_GLOBAL, 0);
 +extern char curdir[];
 
 I thought scoped externs like this were frowned on?

I would make it a normal declaration if it is decided that this is the
right fix :)

Joerg

 
 +Var_Set(.PARSEDIR, curdir, VAR_GLOBAL, 0);
  Var_Set(.PARSEFILE, filename, VAR_GLOBAL, 0);