|
From: Nicholas N. <nj...@ca...> - 2004-08-25 21:43:29
|
Hi, What's a good way to find the highest user-space address? One possibility is to look at the address of a stack variable, and round up a bit. This is really simple but assumes that the stack is at the top of the user-space. Another possibility is to poke around with mmaps, and see where they stop succeeding. Unfortunately, this kind of trashes the code/data that is already used in the address space, which gives unpredictable results. Any other ideas? This is with respect to determining (at configure-time) where stage2 should go. thanks N |
|
From: Jeremy F. <je...@go...> - 2004-08-25 22:04:30
|
On Wed, 2004-08-25 at 22:43 +0100, Nicholas Nethercote wrote: > Another possibility is to poke around with mmaps, and see where they stop > succeeding. Unfortunately, this kind of trashes the code/data that is > already used in the address space, which gives unpredictable results. > > Any other ideas? > > This is with respect to determining (at configure-time) where stage2 > should go. I've been thinking about this, but there isn't a good clean way to do it. The best I can come up with is to scan /proc/self/maps for the highest address present, then try to create mmaps from there up, and use a binary search to see how much space is available above the top mapping. I think this should probably be done in stage1 dynamically rather than fixed at config-time, since different processes can have different address-space configurations (and certainly different kernels can). J |
|
From: Eric E. <eri...@fr...> - 2004-08-26 20:27:27
|
Jeremy Fitzhardinge wrote: > I've been thinking about this, but there isn't a good clean way to do > it. The best I can come up with is to scan /proc/self/maps for the > highest address present, then try to create mmaps from there up, and use > a binary search to see how much space is available above the top > mapping. I've had a try at the mmap scanning, splitting the 32bit address space in 256 blocks, and using PROT_READ|PROT_WRITE and MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, which seem legitimate flags for such kind of tests. This is very fast, and could be done systematically at run-time, but... I segfault in mmap(2) at some places. When I skip a few hard-coded addresses, I get a proper overview of memory layout: stack : 0xbffff5ec 0x00000000: SSSSSSSSSSSSSSSS 0x10000000: ................ 0x20000000: ................ 0x30000000: ................ 0x40000000: S............... 0x50000000: ................ 0x60000000: ................ 0x70000000: ................ 0x80000000: ................ 0x90000000: ................ 0xa0000000: ................ 0xb0000000: S..............S 0xc0000000: UUUUUUUUUUUUUUUU 0xd0000000: UUUUUUUUUUUUUUUU 0xe0000000: UUUUUUUUUUUUUUUU 0xf0000000: UUUUUUUUUUUUUUUU stack is an address of a stack variable; S for areas I didn't scan (see later) . for areas available U for areas unavailable (mmap returned -1) The issue obviously is that calling the libc mmap segfaults. This is specified in mmap2 manpage, but not in mmap manpage. I do not understand why the libc mmap, which I have always taken for 'safe' is using the mmap2 syscall, which can fault. I guess it's a bug in libc, and will report it if you agree. I didn't even manage to have a sig handler working when calling a mmap syscalling mmap2, because it seems that the syscall is restarted forever after the handler has been called. Looks like a nasty kernel bug :-P Has someone a clue on that ? This mechanism seems really fast and relevant, except that mmap crashes... I'll have a try using alternate techniques, using: - either directly the old mmap syscall - or trying with shm mappings >>Another possibility is to poke around with mmaps, and see where they stop >>succeeding. Unfortunately, this kind of trashes the code/data that is >>already used in the address space, which gives unpredictable results. Why do you say it trashes the code/data ? mmap should not succeed if the address range is not available, so we won't call munmap, so nothing should be trashed ? > I think this should probably be done in stage1 dynamically rather than > fixed at config-time, since different processes can have different > address-space configurations (and certainly different kernels can). Indeed, I am for doing that at runtime, otherwise it will be a pain for people using a binary distribution and changing their address-space configs. For now it's ok building many stage2 at different addresses, but it doesn't solve the problem of the analysis of the memory layout (which could also greatly help bootstrapping valgrind). -- Eric |
|
From: Eric E. <eri...@fr...> - 2004-08-26 21:10:58
Attachments:
testmem2.c
|
Finally got it working :-) Calling old_mmap strangely crashes too on my box, but using shm to scan the memory is ok: 0x00000000: ........U....... 0x10000000: ................ 0x20000000: ................ 0x30000000: ................ 0x40000000: U............... 0x50000000: ................ 0x60000000: ................ 0x70000000: ................ 0x80000000: ................ 0x90000000: ................ 0xa0000000: ................ 0xb0000000: ...............U 0xc0000000: UUUUUUUUUUUUUUUU 0xd0000000: UUUUUUUUUUUUUUUU 0xe0000000: UUUUUUUUUUUUUUUU 0xf0000000: UUUUUUUUUUUUUUUU This effectively reports as unavailable areas which crashed when calling mmap... (Still don't know why) I attached the code which does the scanning; hope it helps. Thanks for the challenge, I feel less idiot tonight ! Cheers -- Eric |
|
From: Jeremy F. <je...@go...> - 2004-08-26 21:54:52
|
On Thu, 2004-08-26 at 22:27 +0200, Eric Estievenart wrote: > The issue obviously is that calling the libc mmap > segfaults. This is specified in mmap2 manpage, > but not in mmap manpage. I do not understand > why the libc mmap, which I have always taken for 'safe' > is using the mmap2 syscall, which can fault. > I guess it's a bug in libc, and will report it if > you agree. No, mmap does an implicit munmap on the address range if you use MAP_FIXED. > I didn't even manage to have a sig handler working > when calling a mmap syscalling mmap2, because > it seems that the syscall is restarted forever > after the handler has been called. Looks like > a nasty kernel bug :-P If you've gone and unmapped something important, like the sysinfo page, then I'd expect to see something like this. > Why do you say it trashes the code/data ? mmap should not succeed > if the address range is not available, so we won't call munmap, > so nothing should be trashed ? As above: mmap(MAP_FIXED) trashes any previous mapping. J |
|
From: Tom H. <th...@cy...> - 2004-08-26 22:18:51
|
In message <1093557098.3642.3.camel@localhost>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Thu, 2004-08-26 at 22:27 +0200, Eric Estievenart wrote:
> > The issue obviously is that calling the libc mmap
> > segfaults. This is specified in mmap2 manpage,
> > but not in mmap manpage. I do not understand
> > why the libc mmap, which I have always taken for 'safe'
> > is using the mmap2 syscall, which can fault.
> > I guess it's a bug in libc, and will report it if
> > you agree.
>
> No, mmap does an implicit munmap on the address range if you use
> MAP_FIXED.
Yuk. That's horrible. I always thought you got EINVAL if there was
already something mapped at that address.
I see SuS does allow either behaviour, or even that the memory gets
mapped at some other address!
> > I didn't even manage to have a sig handler working
> > when calling a mmap syscalling mmap2, because
> > it seems that the syscall is restarted forever
> > after the handler has been called. Looks like
> > a nasty kernel bug :-P
>
> If you've gone and unmapped something important, like the sysinfo page,
> then I'd expect to see something like this.
So read /proc/self/maps first, and only try mapping areas which
aren't already mapped...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Eric E. <eri...@fr...> - 2004-08-26 22:44:28
|
Tom Hughes wrote: >>No, mmap does an implicit munmap on the address range if you use >>MAP_FIXED. > > Yuk. That's horrible. I always thought you got EINVAL if there was > already something mapped at that address. Agreed. But it's working that way, and we can't change it. I just sent an e-mail to ldp manpages maintainer to add that small precision in mmap manpage. Would have saved me some time... >>If you've gone and unmapped something important, like the sysinfo page, >>then I'd expect to see something like this. Indeed, it generally crashed after I had made a fixed mmap on either the ld.so, libc.so or stack ranges ;-) > So read /proc/self/maps first, and only try mapping areas which > aren't already mapped... Probably it's even not needed to read /proc/self/maps. The shm scanning code I posted properly detects already mapped areas, and is likely to work almost unchanged on all unices, and maybe also on ... argh I can't say its name ;-) There is another alternative, if you don't like shm, which would be to iterate reserving very large blocks at unspecified addresses, divide the size by two when it fails, stop when the size is very small. Then see which ranges we were returned, and munmap everything. These strategies are very fast and can be used at runtime. Regards -- Eric |
|
From: Paul M. <pa...@sa...> - 2004-08-26 22:17:44
|
Nicholas Nethercote writes: > What's a good way to find the highest user-space address? > > One possibility is to look at the address of a stack variable, and round > up a bit. This is really simple but assumes that the stack is at the top > of the user-space. That is always true on Linux on all the architectures that Valgrind has been ported to. :) Well, it's almost true, since we might have a VDSO just above the stack, but it's true to say that we can't mmap anything at any higher address than the stack. I have the same problem on PPC. Some ppc32 kernels let userspace use 2GB, some 3GB, and ppc64 kernels give 32-bit userspace programs a whole 4GB. I'm tempted to compile stage2 with -fpic (or -fPIC) and teach the ume stuff how to do the necessary relocations, so that stage2 can be loaded at any address. Paul. |
|
From: Jeremy F. <je...@go...> - 2004-08-26 23:08:46
|
On Fri, 2004-08-27 at 08:17 +1000, Paul Mackerras wrote: > I have the same problem on PPC. Some ppc32 kernels let userspace use > 2GB, some 3GB, and ppc64 kernels give 32-bit userspace programs a > whole 4GB. I'm tempted to compile stage2 with -fpic (or -fPIC) and > teach the ume stuff how to do the necessary relocations, so that > stage2 can be loaded at any address. I'd like to avoid even more arch-specific code. Surely there's a small number of useful addresses? Would just pre-generating a series of stage2's at those useful addresses, and then picking the most appropriate work? J |
|
From: Oswald B. <os...@kd...> - 2004-08-27 08:31:02
|
On Fri, Aug 27, 2004 at 08:17:47AM +1000, Paul Mackerras wrote: > Nicholas Nethercote writes: > > One possibility is to look at the address of a stack variable, and > > round up a bit. This is really simple but assumes that the stack is > > at the top of the user-space. > > That is always true on Linux on all the architectures that Valgrind > has been ported to. :) Well, it's almost true, since we might have a > VDSO just above the stack, but it's true to say that we can't mmap > anything at any higher address than the stack. > it's been at least discussed to move the stack down; i think ingo (?) even had some patches in/for redhat already. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Nicholas N. <nj...@ca...> - 2004-08-29 11:43:02
|
On Sat, 28 Aug 2004, Bob Friesenhahn wrote: > Automake allows you to set compilation flags on a per-program (or > per-library) basis. A single source file can be included in several programs, > and it will potentially be compiled with different flags for each program. > That means if these objects are put in a library you could do: > > lib_vgfoopic_SOURCES=vg_replace_malloc.c vg_intercept.c vg_libpthread.c > lib_vgfoopic_CFLAGS=-fno-omit-frame-pointer -g -fPIC > > lib_vgnonpic_SOURCES=vg_replace_malloc.c vg_intercept.c vg_libpthread.c > lib_vgnonpic_CFLAGS=-fno-omit-frame-pointer -g That's useful, but AFAICT automake does not allow you to use different compilation flags for different modules within the same program/library. N |
|
From: Nicholas N. <nj...@ca...> - 2004-08-29 13:41:03
|
On Fri, 27 Aug 2004, Paul Mackerras wrote: > In fact the correct switch for linking is -pie. It seems you still > need -fpie for compiling, although I would have expected -pie to imply > -fpie. What would the configure-time test for PIE support involve? N |
|
From: Tom H. <th...@cy...> - 2004-08-29 14:42:14
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Fri, 27 Aug 2004, Paul Mackerras wrote:
>
> > In fact the correct switch for linking is -pie. It seems you still
> > need -fpie for compiling, although I would have expected -pie to imply
> > -fpie.
>
> What would the configure-time test for PIE support involve?
Something like this should do it:
Index: configure.in
===================================================================
RCS file: /home/kde/valgrind/configure.in,v
retrieving revision 1.120
diff -u -u -r1.120 configure.in
--- configure.in 29 Aug 2004 09:46:38 -0000 1.120
+++ configure.in 29 Aug 2004 14:39:30 -0000
@@ -345,7 +345,18 @@
AC_SUBST(PREFERRED_STACK_BOUNDARY)
-
+# Check for PIE support in the compiler and linker
+AC_CACHE_CHECK([for PIE support], vg_cv_pie,
+ [safe_CFLAGS=$CFLAGS
+ CFLAGS="$CFLAGS -fpie"
+ safe_LDFLAGS=$LDFLAGS
+ LDFLAGS="$LDFLAGS -pie"
+ AC_TRY_LINK([int foo;],
+ [],
+ [vg_cv_pie=yes],
+ [vg_cv_pie=no])
+ CFLAGS=$safe_CFLAGS
+ LDFLAGS=$safe_LDFLAGS])
# Checks for header files.
AC_HEADER_STDC
That was stolen from glibc and then rewritten more in the style
suggested by the autoconf documentation. After that vg_cv_pie should
be set to yes if PIE support is available.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-26 22:22:44
|
On Fri, 27 Aug 2004, Paul Mackerras wrote: >> What's a good way to find the highest user-space address? >> >> One possibility is to look at the address of a stack variable, and round >> up a bit. This is really simple but assumes that the stack is at the top >> of the user-space. > > That is always true on Linux on all the architectures that Valgrind > has been ported to. :) Well, it's almost true, since we might have a > VDSO just above the stack, but it's true to say that we can't mmap > anything at any higher address than the stack. > > I have the same problem on PPC. Some ppc32 kernels let userspace use > 2GB, some 3GB, and ppc64 kernels give 32-bit userspace programs a > whole 4GB. I'm tempted to compile stage2 with -fpic (or -fPIC) and > teach the ume stuff how to do the necessary relocations, so that > stage2 can be loaded at any address. That would be better, but Jeremy is of the opinion that loading PIC is (a) difficult and (b) platform-specific. My patch providing multiple versions of stage2 (which I posted earlier today) is a simple and not-too-bad alternative. N |
|
From: Paul M. <pa...@sa...> - 2004-08-27 09:57:20
|
Nicholas Nethercote writes:
> That would be better, but Jeremy is of the opinion that loading PIC is (a)
> difficult and (b) platform-specific. My patch providing multiple versions
> of stage2 (which I posted earlier today) is a simple and not-too-bad
> alternative.
Just today I learned that gcc-3.4 and later plus current binutils is
capable of producing position-independent executables, or PIE for
short. If you compile with -fpie and link with -Wl,-pie, the linker
will link the executable with base address 0 and include all the
relocations needed to run the executable at any address. What's more,
ld.so takes care of doing all the relocations for you.
I tried this out with a little hello world program and a slightly
modified version of stage1.c and ume.c. All that I had to change was
to add the base address where I wanted the executable loaded to the
value of e->e.e_entry and the PT_PHDR ph->p_vaddr value. The patch
below shows exactly what I had to change. In the patch I use the
constant 0x60000000 but of course for Valgrind we would choose that
value based on the stack address or something similar.
This works on x86 and almost works on PPC (modulo some bugs in ld.so
and the gcc compiler driver that can be worked around). The only
downside is the need to use gcc-3.4 or later.
Paul.
diff -urN ume.c ume-pie.c
--- ume.c 2004-08-18 23:08:59.000000000 +1000
+++ ume-pie.c 2004-08-27 15:31:54.000000000 +1000
@@ -423,6 +423,7 @@
ESZ(Word) interp_align = VKI_BYTES_PER_PAGE;
int i;
void *entry;
+ ESZ(Addr) exebase = 0x60000000;
e = readelf(fd, name);
@@ -430,14 +431,14 @@
return ENOEXEC;
info->phnum = e->e.e_phnum;
- info->entry = e->e.e_entry;
+ info->entry = e->e.e_entry + exebase;
for(i = 0; i < e->e.e_phnum; i++) {
ESZ(Phdr) *ph = &e->p[i];
switch(ph->p_type) {
case PT_PHDR:
- info->phdr = ph->p_vaddr;
+ info->phdr = ph->p_vaddr + exebase;
break;
case PT_LOAD:
@@ -495,6 +496,7 @@
}
}
+#if 0
if (info->exe_base != info->exe_end) {
if (minaddr >= maxaddr ||
(minaddr < info->exe_base ||
@@ -506,8 +508,9 @@
return ENOMEM;
}
}
+#endif
- info->brkbase = mapelf(e, 0); /* map the executable */
+ info->brkbase = mapelf(e, exebase); /* map the executable */
if (info->brkbase == 0)
return ENOMEM;
|
|
From: Tom H. <th...@cy...> - 2004-08-27 10:27:27
|
In message <166...@ca...>
Paul Mackerras <pa...@sa...> wrote:
> Just today I learned that gcc-3.4 and later plus current binutils is
> capable of producing position-independent executables, or PIE for
> short. If you compile with -fpie and link with -Wl,-pie, the linker
> will link the executable with base address 0 and include all the
> relocations needed to run the executable at any address. What's more,
> ld.so takes care of doing all the relocations for you.
My Fedora Core 2 box claims to support PIE in gcc and it only
has version 3.3.3.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Paul M. <pa...@sa...> - 2004-08-27 10:56:10
|
Tom Hughes writes: > In message <166...@ca...> > Paul Mackerras <pa...@sa...> wrote: > > > Just today I learned that gcc-3.4 and later plus current binutils is > > capable of producing position-independent executables, or PIE for > > short. If you compile with -fpie and link with -Wl,-pie, the linker > > will link the executable with base address 0 and include all the > > relocations needed to run the executable at any address. What's more, > > ld.so takes care of doing all the relocations for you. > > My Fedora Core 2 box claims to support PIE in gcc and it only > has version 3.3.3. That's great. In fact my resident toolchain expert tells me that using -fpic for the .c -> .o step will also work (the difference is that -fpic means that the compiler can't assume that calls to non-static functions are local). So the main constraint is whether the linker has PIE support. It looks like the PIE binutils support went in in June 2003. We could test for PIE support in configure.in and use it if present, otherwise link at a fixed address like we do at the moment. Paul. |
|
From: Nicholas N. <nj...@ca...> - 2004-08-27 11:29:15
|
On Fri, 27 Aug 2004, Paul Mackerras wrote: > We could test for PIE support in configure.in and use it if present, > otherwise link at a fixed address like we do at the moment. Indeed, that sounds like a pretty good solution. N |
|
From: Paul M. <pa...@sa...> - 2004-08-27 11:20:23
|
Correcting myself... > If you compile with -fpie and link with -Wl,-pie, the linker > will link the executable with base address 0 and include all the > relocations needed to run the executable at any address. What's more, > ld.so takes care of doing all the relocations for you. In fact the correct switch for linking is -pie. It seems you still need -fpie for compiling, although I would have expected -pie to imply -fpie. Paul. |
|
From: Jeremy F. <je...@go...> - 2004-08-27 21:55:33
|
On Fri, 2004-08-27 at 19:57 +1000, Paul Mackerras wrote: > Nicholas Nethercote writes: > > > That would be better, but Jeremy is of the opinion that loading PIC is (a) > > difficult and (b) platform-specific. My patch providing multiple versions > > of stage2 (which I posted earlier today) is a simple and not-too-bad > > alternative. > > Just today I learned that gcc-3.4 and later plus current binutils is > capable of producing position-independent executables, or PIE for > short. If you compile with -fpie and link with -Wl,-pie, the linker > will link the executable with base address 0 and include all the > relocations needed to run the executable at any address. What's more, > ld.so takes care of doing all the relocations for you. If this is stage2's ld.so, then that should work nicely. J |
|
From: Paul M. <pa...@sa...> - 2004-08-28 00:57:24
|
Jeremy Fitzhardinge writes: > If this is stage2's ld.so, then that should work nicely. Yes, it is, precisely. In trying to actually implement this the main difficulty I have struck is that we now have 3 different sets of compile flags we need to use, and it's hard to do that with automake in a single directory. Ideally we would have most things compiled with -fpie, a few things compiled with -fpic (the bits that go into libpthread.so and vg_inject.so) and some things compiled with neither (stage1.c, ume.c, ume_go.c). In fact we want ume.c compiled both with -fpic and without. In practice it seems that compiling everything with -fpic will work. I think that this line in coregrind/Makefile.am works more by the grace of GNU make than anything else: vg_replace_malloc.o vg_intercept.o vg_libpthread.o: CFLAGS += -fno-omit-frame-pointer -g -fPIC I believe that automake gives up on thinking it knows anything about those object files at that point and we end up relying on make's implicit rules. I say this because I tried to add an object to that line whose source was in a subdirectory, and at that point make could no longer find the source for that object. Looking in the generated Makefile I saw that where automake had previously generated a dependency and rule to generate the object from the source in the subdirectory, that dependency and rule was now commented out. Paul. |
|
From: Jeremy F. <je...@go...> - 2004-08-28 05:58:40
|
On Sat, 2004-08-28 at 10:57 +1000, Paul Mackerras wrote: > In practice it seems that compiling everything with -fpic will work. Yes, that shouldn't be a problem; none of the code which doesn't need it is performance critical. > I think that this line in coregrind/Makefile.am works more by the > grace of GNU make than anything else: > > vg_replace_malloc.o vg_intercept.o vg_libpthread.o: CFLAGS += -fno-omit-frame-pointer -g -fPIC > > I believe that automake gives up on thinking it knows anything about > those object files at that point and we end up relying on make's > implicit rules. I say this because I tried to add an object to that > line whose source was in a subdirectory, and at that point make could > no longer find the source for that object. Looking in the generated > Makefile I saw that where automake had previously generated a > dependency and rule to generate the object from the source in the > subdirectory, that dependency and rule was now commented out. I believe I've already used the phrase "teetering pile" with respect to automake/autoconf/gmake. Is there a proper automake-ish way of doing this? J |
|
From: Bob F. <bfr...@si...> - 2004-08-28 14:58:56
|
On Fri, 27 Aug 2004, Jeremy Fitzhardinge wrote: > On Sat, 2004-08-28 at 10:57 +1000, Paul Mackerras wrote: >> In practice it seems that compiling everything with -fpic will work. > > Yes, that shouldn't be a problem; none of the code which doesn't need it > is performance critical. > >> I think that this line in coregrind/Makefile.am works more by the >> grace of GNU make than anything else: >> >> vg_replace_malloc.o vg_intercept.o vg_libpthread.o: CFLAGS += -fno-omit-frame-pointer -g -fPIC >> > I believe I've already used the phrase "teetering pile" with respect to > automake/autoconf/gmake. Is there a proper automake-ish way of doing > this? Automake allows you to set compilation flags on a per-program (or per-library) basis. A single source file can be included in several programs, and it will potentially be compiled with different flags for each program. That means if these objects are put in a library you could do: lib_vgfoopic_SOURCES=vg_replace_malloc.c vg_intercept.c vg_libpthread.c lib_vgfoopic_CFLAGS=-fno-omit-frame-pointer -g -fPIC lib_vgnonpic_SOURCES=vg_replace_malloc.c vg_intercept.c vg_libpthread.c lib_vgnonpic_CFLAGS=-fno-omit-frame-pointer -g When you use this approach, the object files are given extended names in order to make sure that object files do not collide. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Tom H. <th...@cy...> - 2004-08-29 11:48:33
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Sat, 28 Aug 2004, Bob Friesenhahn wrote:
>
> > Automake allows you to set compilation flags on a per-program (or
> > per-library) basis. A single source file can be included in several programs,
> > and it will potentially be compiled with different flags for each program.
> > That means if these objects are put in a library you could do:
> >
> > lib_vgfoopic_SOURCES=vg_replace_malloc.c vg_intercept.c vg_libpthread.c
> > lib_vgfoopic_CFLAGS=-fno-omit-frame-pointer -g -fPIC
> >
> > lib_vgnonpic_SOURCES=vg_replace_malloc.c vg_intercept.c vg_libpthread.c
> > lib_vgnonpic_CFLAGS=-fno-omit-frame-pointer -g
>
> That's useful, but AFAICT automake does not allow you to use different
> compilation flags for different modules within the same program/library.
Presumably you can always build the files which need different
flags into a library and then build the final program/library
against that library?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-29 12:17:31
|
On Sun, 29 Aug 2004, Tom Hughes wrote: >> That's useful, but AFAICT automake does not allow you to use different >> compilation flags for different modules within the same program/library. > > Presumably you can always build the files which need different > flags into a library and then build the final program/library > against that library? Hmm, I guess. Pretty kludgey way to have to do it. N |