History log of /fuchsia/zircon/system/ulib/bitmap/rules.mk
Revision Date Author Comments
# 6ae8c893 21-Sep-2018 George Kulakowski <kulakowski@google.com>

[bitmap] Make bitmap a static library and use -fvisibility=hidden

ZX-1895 #comment

Test: cq
Change-Id: Ia4a3ad32e78ac3cbe12bc40c01d55a5e1835d126


# 6a06a745 25-May-2018 Sean Klein <smklein@google.com>

[bitmap] Avoid exporting ulib/bitmap as a shared library

Since ulib/bitmap exposes a C++ interface, expose it as
source, not as a shared library.

Exposing ulib/bitmap as a shared library breaks the
invariant that Zircon .so files have C ABI.

Change-Id: I3052bdb5ecda805e2e35c29aa6ac9ad644f70494


# d53ea9b2 06-Feb-2018 P.Y. Laligand <pylaligand@google.com>

[build] Remove a few more GN files.

TO-732

Change-Id: I3d54c34deee3ddfd88705bbbfa4a9503b0bb001a


# f3e2126c 12-Sep-2017 Roland McGrath <mcgrathr@google.com>

[zx] Magenta -> Zircon

The Great Renaming is here!

Change-Id: I3229bdeb2a3d0e40fb4db6fec8ca7d971fbffb94


# 59e644b1 07-Sep-2017 George Kulakowski <kulakowski@google.com>

[zircon][mxtl->fbl] Rename mxtl to fbl

Change-Id: Ie21b6498e1bfb0a7fa0315e40b9e5c3ee78646be


# 10a03ab6 03-Aug-2017 Jeff Brown <jeffbrown@google.com>

[mxtl][mxalloc] Redirect all clients of mxalloc to mxtl.

Change-Id: Ib6d88937212ab23612f59add8bd028862308ead5


# 1d47310a 15-May-2017 Sean Klein <smklein@google.com>

[minfs] Convert MinFS, bitmap to use libmx handles

Change-Id: Id0a90f523496d04d6012cf6f04ff04c757224c23


# 1fb8124a 16-May-2017 George Kulakowski <kulakowski@google.com>

[mxcpp][mxalloc] Split mxcpp into mxcpp and mxalloc

mxcpp used to provide three things.

(1) is a very minimal C++ runtime environment. This means essentially
the definition of __cxa_pure_virtual, which is a function the compiler
expects to have ambient. This functionality is necessary for code
written in environments which cannot link the standard library (the
kernel and a handful of initial userspace processes).

(2) is the definitions of the standard new and delete
overloads. Again, these are needed for code that wants to call them
but to not link the standard library, but this time only in userspace
(the kernel does not want certain behavior stemming from the standard
overloads). The behavior is slightly different than the standard ones
in failure cases, but not in a way particularly interesting to the
rest of this email.

(3) is the userspace version of our special AllocChecker new
overloads. This mechanism exists for kernelspace, where allocation
failure is real and needs to be handled. This mechanism works
perfectly well in userspace, in that it compiles, even though the
underlying allocator is unlikely to ever return nullptr. It's
therefore essentially harmless in userspace. A handful of small
libraries are used in both userspace and in the kernel, and also use
this mechanism. Note that this feature is essentially copy-pasted
between the kernel and userspace.

This all works perfectly well for the kernel.

Some userspace code also uses these mechanisms, as mentioned. As long
as the standard library isn't linked, there are again no issues.

But as soon as you want both (3) and std::vector, which is a
reasonable thing to want!, there are issues because (1) and (3) come
in the same static library. This causes link failures due to duplicate
__cxa_pure_virtual symbols. This issue is exacerbated by different
behavior in Linux, OS X, and target linkage, in terms of confusion and
it-works-on-my-machine sort of issues.

This patch splits mxcpp into: mxcpp, containing (1) __cxa_pure_virtual
and (2) only if in userspace, the standard new and delete overloads;
and mxalloc, containing (3) AllocChecker. mxcpp is mutually exclusive
of the standard library. mxalloc can be linked against both code using
the standard library, and against code using mxcpp.

This patch also deduplicates the AllocChecker between userspace and
kernel, and moves the InlineArray class into the kernel (its only
callsites are in the kernel).

Change-Id: Id42d5d019ee977d44d6cb89ce7ab6884f7a56cd1


# 91125e0a 23-Apr-2017 Roland McGrath <mcgrathr@google.com>

[ulib] Make mxtl, mxcpp, and mx libraries static-only

mxtl is actually a header-only library, so don't build a
shared object for it.

The mxtl and mx libraries are already built only as static
libraries in the Fuchsia GN build. Their code is very small.
Make the Magenta make build follow suit.

Change-Id: Ia79e5a996a981a8b046370d4ece9597f8e5bd1c2


# 16656ae0 05-Apr-2017 Brian Swetland <swetland@google.com>

[build] flatten the build

Previously we treated kernel/, system/, and third_party/ as
overlays on a shared namespace. This required the concept
of "canonical" module names, and a lot of complexity to ensure
that things didn't collide and the build worked.

This change gets rid of that, no longer passes -I to make,
so that include directives from our *.mk files do not magically
wildcard across various paths, etc.

The most user-visible change is that everywhere where a module
name is specified (MODULE_DEPS, MODULE_LIBS, etc), full module
names like kernel/lib/io or system/ulib/mxio must be used instead
of previously-allowed "short" names like lib/io and ulib/mxio.

The build output still has a similar shape, but the first segment
of the module path (kernel/, system/, or third_party/) is no
longer elided under $(BUILDDIR)

Change-Id: I525aba1da1c86eb7a86007bddc669f7eeebfedd5


# 12242caa 07-Mar-2017 Brian Swetland <swetland@google.com>

[build][musl] refer to musl libc as ulib/c

This makes the build rules and the intermediate
output files easier to understand, without having
to modify the path where musl libc lives.

The biggest observeable difference is the build
intermediate files:

$ ls build-magenta-pc-x86-64/ulib/c
config-module.h libc.abi.h libc.abi.stamp libc.so libc.so.id libc.so.strip
libc.a libc.abi.o libc.a.opts libc.so.abi libc.so.opts third_party

which previously were at build-magenta-pc-x86/ulib/musl
and named libmusl.*

and the replacing of ulib/musl with ulib/c in the library
dependencies of all the rules.mk files (the vast bulk of
this change)

Change-Id: If9c5d522099d2c9ac5bdb666b8e67a2eb3d316ee


# 5ca4e1e9 02-Mar-2017 Sean Klein <smklein@google.com>

[bitmap] Enable VMO-backed bitmap storage

- Also updates the MinFS client, which uses the raw-bitmap,
to use a VMO-backed bitmap instead of an unaligned, anonymous
memory bitmap. This will (in the future) allow us to use the
high speed FIFO / VMO protocol to update bitmap metadata.
- Updated raw bitmap tests to allow for templatization.

Change-Id: I866799016726ba0f1c4186580f5808ebf6683ae3


# 4413ba33 09-Nov-2016 Aaron Green <aarongreen@google.com>

[bitmap] Add RawBitmap

This CL adds a bitmap backed by an array of uint64_t's.

Change-Id: I7996116493df7a0bfa45545aa48a4997a8808fb8


# f6c75589 05-Nov-2016 Brian Swetland <swetland@google.com>

[build] whitelist libraries for sysroot

The sysroot should be carefully curated, not blindly include
every library that we happen to build within the magenta build.

MODULE_EXPORT is now used to indicate a library belongs in sysroot,
either as static "a", shared "so", or both "a so".

MODULE_NAME can override the static library base name if desired,
similar to how it overrides the installed binary name for apps.

Change-Id: Id97163a46e6ade155e82ad88ebcb68d48e243f57


# 12acd9ac 25-Oct-2016 Todd Eisenberger <teisenbe@google.com>

[lib][bitmap] Add dual-mode library for run-length encoded bitmaps

Change-Id: I0ea5e6533135721ebd596b63f9b47aebc4e706ca