aboutsummaryrefslogtreecommitdiff
path: root/gdb/mdebugread.c
AgeCommit message (Collapse)AuthorFilesLines
2024-10-06[gdb] Fix more common misspellingsTom de Vries1-1/+1
Fix the following common misspellings: ... addres -> address, adders behavour -> behavior, behaviour intented -> intended, indented ther -> there, their, the throught -> thought, through, throughout ... Tested on x86_64-linux.
2024-10-06[gdb] Fix common misspellingsTom de Vries1-3/+3
Fix the following common misspellings: ... accidently -> accidentally additonal -> additional addresing -> addressing adress -> address agaisnt -> against albiet -> albeit arbitary -> arbitrary artifical -> artificial auxillary -> auxiliary auxilliary -> auxiliary bcak -> back begining -> beginning cannonical -> canonical compatiblity -> compatibility completetion -> completion diferent -> different emited -> emitted emiting -> emitting emmitted -> emitted everytime -> every time excercise -> exercise existance -> existence fucntion -> function funtion -> function guarentee -> guarantee htis -> this immediatly -> immediately layed -> laid noone -> no one occurances -> occurrences occured -> occurred originaly -> originally preceeded -> preceded preceeds -> precedes propogate -> propagate publically -> publicly refering -> referring substract -> subtract substracting -> subtracting substraction -> subtraction taht -> that targetting -> targeting teh -> the thier -> their thru -> through transfered -> transferred transfering -> transferring upto -> up to vincinity -> vicinity whcih -> which whereever -> wherever wierd -> weird withing -> within writen -> written wtih -> with doesnt -> doesn't ... Tested on x86_64-linux.
2024-09-20gdb: Move dbx_end_psymtab to stabsread, and rename to stabs_end_psymtabGuinevere Larsen1-8/+8
This function is used by multiple stabs readers (even if not all), and the comment in stabsread.h even acknowledges it. I believe that the comment is incorrect in saying that the function should be in dbxread because not everyone uses it. If any one reader other than dbx uses it, the function should be in stabsread, in my opinion. This commit makes also renames the function to stabs_end_psymtab since, again, this is not specific to dbx/aout format. struct symloc had to be moved because stabs_end_psymtab dereferences symloc objects, so stabsread.c must be aware of the full struct. Approved-By: Tom Tromey <tom@tromey.com>
2024-09-13Update more types for section index changeTom Tromey1-2/+2
Commit f89276a2f3e ("change type of `general_symbol_info::m_section` to int") did what it says in the title -- changed the type of the section index from short to int. However, it seems incomplete, in that there are uses of the section index that use the type 'short'. This patch fixes the ones I found, first by searching for "short.*sect" and then by looking at all the callers of section_index (and then functions called with the resulting value) just to try to be more sure. Approved-by: Kevin Buettner <kevinb@redhat.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi1-1/+0
Now that defs.h, server.h and common-defs.h are included via the `-include` option, it is no longer necessary for source files to include them. Remove all the inclusions of these files I could find. Update the generation scripts where relevant. Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 Approved-By: Pedro Alves <pedro@palves.net>
2024-01-28Use the new symbol domainsTom Tromey1-2/+2
This patch changes the DWARF reader to use the new symbol domains. It also adjusts many bits of associated code to adapt to this change. The non-DWARF readers are updated on a best-effort basis. This is somewhat simpler since most of them only support C and C++. I have no way to test a few of these. I went back and forth a few times on how to handle the "tag" situation. The basic problem is that C has a special namespace for tags, which is separate from the type namespace. Other languages don't do this. So, the question is, should a DW_TAG_structure_type end up in the tag domain, or the type domain, or should it be language-dependent? I settled on making it language-dependent using a thought experiment. Suppose there was a Rust compiler that only emitted nameless DW_TAG_structure_type objects, and specified all structure type names using DW_TAG_typedef. This DWARF would be correct, in that it faithfully represents the source language -- but would not work with a purely struct-domain implementation in gdb. Therefore gdb would be wrong. Now, this approach is a little tricky for C++, which uses tags but also enters a typedef for them. I notice that some other readers -- like stabsread -- actually emit a typedef symbol as well. And, I think this is a reasonable approach. It uses more memory, but it makes the internals simpler. However, DWARF never did this for whatever reason, and so in the interest of keeping the series slightly shorter, I've left some C++-specific hacks in place here. Note that this patch includes language_minimal as a language that uses tags. I did this to avoid regressing gdb.dwarf2/debug-names-tu.exp, which doesn't specify the language for a type unit. Arguably this test case is wrong. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30164
2024-01-28Fix latent bug in mdebugread.cTom Tromey1-1/+1
mdebugread.c makes a label symbol but puts it into VAR_DOMAIN. I think LABEL_DOMAIN is more appropriate. I don't have a way to test this.
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2023-11-29Use C++17 [[fallthrough]] attributeTom Tromey1-3/+3
This changes gdb to use the C++17 [[fallthrough]] attribute rather than special comments. This was mostly done by script, but I neglected a few spellings and so also fixed it up by hand. I suspect this fixes the bug mentioned below, by switching to a standard approach that, presumably, clang supports. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23159 Approved-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-11-21gdb: Use std::string_view instead of gdb::string_viewLancelot Six1-9/+9
Given that GDB now requires a C++17, replace all uses of gdb::string_view with std::string_view. This change has mostly been done automatically: - gdb::string_view -> std::string_view - #include "gdbsupport/gdb_string_view.h" -> #include <string_view> One things which got brought up during review is that gdb::stging_view does support being built from "nullptr" while std::sting_view does not. Two places are manually adjusted to account for this difference: gdb/tui/tui-io.c:tui_getc_1 and gdbsupport/format.h:format_piece::format_piece. The above automatic change transformed "gdb::to_string (const gdb::string_view &)" into "gdb::to_string (const std::string_view &)". The various direct users of this function are now explicitly including "gdbsupport/gdb_string_view.h". A later patch will remove the users of gdb::to_string. The implementation and tests of gdb::string_view are unchanged, they will be removed in a following patch. Change-Id: Ibb806a7e9c79eb16a55c87c6e41ad396fecf0207 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-09-20Remove explanatory comments from includesTom Tromey1-3/+3
I noticed a comment by an include and remembered that I think these don't really provide much value -- sometimes they are just editorial, and sometimes they are obsolete. I think it's better to just remove them. Tested by rebuilding. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-09-19Give a language to a typeTom Tromey1-4/+5
This changes main_type to hold a language, and updates the debug readers to set this field. This is done by adding the language to the type-allocator object. Note that the non-DWARF readers are changed on a "best effort" basis. This patch also reimplements type::is_array_like to use the type's language, and it adds a new type::is_string_like as well. This in turn lets us change the Python implementation of these methods to simply defer to the type.
2023-09-12gdb: Fix -Wuninitialized issueEnze Li1-0/+1
I see the following warning when building GDB on FreeBSD/amd64 with Clang 14, ====================================================================== CXX mdebugread.o mdebugread.c:1069:3: error: variable 'f' is uninitialized when used here [-Werror,-Wuninitialized] f->set_loc_enumval (tsym.value); ^ mdebugread.c:836:17: note: initialize the variable 'f' to silence this warning struct field *f; ^ = nullptr ====================================================================== after digging a little, I realized that we can not simply do what Clang 14 says. The root cause of this issue is that we lost the initialization of the variable 'f' in this commit, commit 2774f2dad5f05e68771c07df6ab0fb23baa2118e Date: Thu Aug 31 09:37:44 2023 +0200 [gdb/symtab] Factor out type::{alloc_fields,copy_fields} we have made these modifications, --------------------------------------------------------------------- --- a/gdb/mdebugread.c +++ b/gdb/mdebugread.c @@ -1034,9 +1034,7 @@ parse_symbol (SYMR *sh, union aux_ext *ax, char *ext_sh, int bigend, t->set_code (type_code); t->set_length (sh->value); - t->set_num_fields (nfields); - f = ((struct field *) TYPE_ALLOC (t, nfields * sizeof (struct field))); - t->set_fields (f); + t->alloc_fields (nfields, false); --------------------------------------------------------------------- The problem is that the variable 'f' is used in the second half of parse_symbol, that's why Clang complained. To fix this issue we need to ensure that the varibale 'f' is initialized. Calling the fields method is an obvious way to fix this issue. Tested on FreeBSD/amd64 by rebuilding. Approved-By: Tom de Vries <tdevries@suse.de>
2023-08-31gdb: introduce field::bitsize / field::set_bitsizeSimon Marchi1-2/+2
Add these two methods, rename the field to m_bitsize to make it pseudo private. Change-Id: Ief95e5cf106e72f2c22ae47b033d0fa47202b413 Approved-By: Tom Tromey <tom@tromey.com>
2023-08-31gdb: introduce field::is_artificial / field::set_is_artificialSimon Marchi1-1/+1
Add these two methods, rename the field to m_artificial to make it pseudo private. Change-Id: If3a3825473d1d79bb586a8a074b87bba9b43fb1a Approved-By: Tom Tromey <tom@tromey.com>
2023-08-31[gdb/symtab] Do more zero-initialization of type::fieldsTom de Vries1-2/+2
Now that we've introduced type::{alloc_fields,copy_fields}, the places where no zero-initialization of allocated fields is done are easy to spot: ... $ find gdb* -type f | grep -v ChangeLog | xargs grep alloc_fields | grep false gdb/coffread.c: type->alloc_fields (nfields, false); gdb/coffread.c: type->alloc_fields (nsyms, false); gdb/stabsread.c: ftype->alloc_fields (nsemi, false); gdb/gdbtypes.c: resolved_type->alloc_fields (nfields, false); gdb/gdbtypes.c: alloc_fields (nfields, false); gdb/gdbtypes.c: alloc_fields (nfields, false); gdb/mdebugread.c: t->alloc_fields (nfields, false); gdb/mdebugread.c: ftype->alloc_fields (nparams, false); ... All hits in gdbtypes.c are ok. There are two hits in the two variants of copy_fields, and there's already a comment for the third. AFAICT, the other ones are not ok, so fix those by dropping the "false" argument. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2023-08-31[gdb/symtab] Factor out type::{alloc_fields,copy_fields}Tom de Vries1-7/+2
After finding this code in buildsym_compunit::finish_block_internal: ... ftype->set_fields ((struct field *) TYPE_ALLOC (ftype, nparams * sizeof (struct field))); ... and fixing PR30810 by using TYPE_ZALLOC, I wondered if there were more locations that needed fixing. I decided to make things easier to spot by factoring out a new function alloc_fields: ... /* Allocate the fields array of this type, with NFIELDS elements. If INIT, zero-initialize the allocated memory. */ void type::alloc_fields (unsigned int nfields, bool init = true); ... where: - a regular use would be "alloc_fields (nfields)", and - an exceptional use that needed no initialization would be "alloc_fields (nfields, false)". Pretty soon I discovered that most of the latter cases are due to initialization by memcpy, so I added two variants of copy_fields as well. After this rewrite there are 8 uses of set_fields left: ... gdb/coffread.c: type->set_fields (nullptr); gdb/coffread.c: type->set_fields (nullptr); gdb/coffread.c: type->set_fields (nullptr); gdb/eval.c: type->set_fields gdb/gdbtypes.c: type->set_fields (args); gdb/gdbtypes.c: t->set_fields (XRESIZEVEC (struct field, t->fields (), gdb/dwarf2/read.c: type->set_fields (new_fields); gdb/dwarf2/read.c: sub_type->set_fields (sub_type->fields () + 1); ... These fall into the following categories: - set to nullptr (coffread.c), - type not owned by objfile or gdbarch (eval.c), and - modifying an existing fields array, like adding an element at the end or dropping an element at the start (the rest). Tested on x86_64-linux.
2023-08-18Merge psympriv.h into psymtab.hTom Tromey1-1/+1
psympriv.h was intended for use by code that created partial symbols. Now that no generic code needs psymtab.h any more, psympriv.h can be merged into psymtab.h.
2023-06-05Use "unrelocated" terminology in linetable_entryTom Tromey1-1/+1
I forgot to convert struct linetable_entry to use the "unrelocated" (as opposed to "raw") terminology. This patch corrects the oversight.
2023-06-03[gdb] Fix typosTom de Vries1-1/+1
Fix a few typos: - implemention -> implementation - convertion(s) -> conversion(s) - backlashes -> backslashes - signoring -> ignoring - (un)ambigious -> (un)ambiguous - occured -> occurred - hidding -> hiding - temporarilly -> temporarily - immediatelly -> immediately - sillyness -> silliness - similiar -> similar - porkuser -> pokeuser - thats -> that - alway -> always - supercede -> supersede - accomodate -> accommodate - aquire -> acquire - priveleged -> privileged - priviliged -> privileged - priviledges -> privileges - privilige -> privilege - recieve -> receive - (p)refered -> (p)referred - succesfully -> successfully - successfuly -> successfully - responsability -> responsibility - wether -> whether - wich -> which - disasbleable -> disableable - descriminant -> discriminant - construcstor -> constructor - underlaying -> underlying - underyling -> underlying - structureal -> structural - appearences -> appearances - terciarily -> tertiarily - resgisters -> registers - reacheable -> reachable - likelyhood -> likelihood - intepreter -> interpreter - disassemly -> disassembly - covnersion -> conversion - conviently -> conveniently - atttribute -> attribute - struction -> struct - resonable -> reasonable - popupated -> populated - namespaxe -> namespace - intialize -> initialize - identifer(s) -> identifier(s) - expection -> exception - exectuted -> executed - dungerous -> dangerous - dissapear -> disappear - completly -> completely - (inter)changable -> (inter)changeable - beakpoint -> breakpoint - automativ -> automatic - alocating -> allocating - agressive -> aggressive - writting -> writing - reguires -> requires - registed -> registered - recuding -> reducing - opeartor -> operator - ommitted -> omitted - modifing -> modifying - intances -> instances - imbedded -> embedded - gdbaarch -> gdbarch - exection -> execution - direcive -> directive - demanged -> demangled - decidely -> decidedly - argments -> arguments - agrument -> argument - amespace -> namespace - targtet -> target - supress(ed) -> suppress(ed) - startum -> stratum - squence -> sequence - prompty -> prompt - overlow -> overflow - memember -> member - languge -> language - geneate -> generate - funcion -> function - exising -> existing - dinking -> syncing - destroh -> destroy - clenaed -> cleaned - changep -> changedp (name of variable) - arround -> around - aproach -> approach - whould -> would - symobl -> symbol - recuse -> recurse - outter -> outer - freeds -> frees - contex -> context Tested on x86_64-linux. Reviewed-By: Tom Tromey <tom@tromey.com>
2023-03-28Rename "raw" to "unrelocated"Tom Tromey1-7/+7
Per an earlier discussion, this patch renames the existing "raw" APIs to use the word "unrelocated" instead.
2023-03-28Use unrelocated_addr in minimal symbolsTom Tromey1-7/+10
This changes minimal symbols to use unrelocated_addr. I believe this detected a latent bug in add_pe_forwarded_sym.
2023-03-28Use unrelocated_addr in psymbolsTom Tromey1-15/+28
This changes psymbols themselves to use unrelocated_addr. This transform is largely mechanical. I don't think it finds any bugs.
2023-03-28Use unrelocated_addr in partial symbol tablesTom Tromey1-13/+19
This changes partial symbol tables to use unrelocated_addr for the text_high and text_low members. This revealed some latent bugs in ctfread.c, which are fixed here.
2023-03-18Rename objfile_type to builtin_typeTom Tromey1-12/+12
This renames objfile_type to be an overload of builtin_type, in preparation for their unification. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Use type allocator for array typesTom Tromey1-1/+1
This changes the array type creation functions to accept a type allocator, and updates all the callers. Note that symbol readers should generally allocate on the relevant objfile, regardless of the placement of the index type of the array, which is what this patch implements. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Use type allocator for range typesTom Tromey1-2/+5
This changes the range type creation functions to accept a type allocator, and updates all the callers. Note that symbol readers should generally allocate on the relevant objfile, regardless of the underlying type of the range, which is what this patch implements. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Unify arch_pointer_type and init_pointer_typeTom Tromey1-2/+2
This unifies arch_pointer_type and init_pointer_type by using a type allocator. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Unify arch_float_type and init_float_typeTom Tromey1-2/+2
This unifies arch_float_type and init_float_type by using a type allocator. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Unify arch_integer_type and init_integer_typeTom Tromey1-15/+15
This unifies arch_integer_type and init_integer_type by using a type allocator. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Remove init_typeTom Tromey1-9/+15
This removes init_type, replacing all uses with the new type allocator. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Remove alloc_typeTom Tromey1-1/+1
This removes alloc_type, replacing all uses with the new type allocator. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-17Fix line table regressionTom Tromey1-3/+5
Simon pointed out a line table regression, and after a couple of false starts, I was able to reproduce it by hand using his instructions. The bug is that most of the code in do_mixed_source_and_assembly uses unrelocated addresses, but one spot does: pc = low; ... after the text offset has been removed. This patch fixes the problem by introducing a new type to represent unrelocated addresses in the line table. This prevents this sort of bug to some degree (it's still possible to manipulate a CORE_ADDR in a bad way, this is unavoidable). However, this did let the compiler flag a few spots in that function, and now it's not possible to compare an unrelocated address from a line table with an ordinary CORE_ADDR. Regression tested on x86-64 Fedora 36, though note this setup never reproduced the bug in the first place. I also tested it by hand on the disasm-optim test program.
2023-03-11Constify linetablesTom Tromey1-1/+4
Linetables no longer change after they are created. This patch applies const to them. Note there is one hack to cast away const in mdebugread.c. This code allocates a linetable using 'malloc', then later copies it to the obstack. While this could be cleaned up, I chose not to do so because I have no way of testing it. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-11Change linetables to be objfile-independentTom Tromey1-5/+4
This changes linetables to not add the text offset to the addresses they contain. I did this in a few steps, necessarily combined together in one patch: I renamed the 'pc' member to 'm_pc', added the appropriate accessors, and then recompiled. Then I fixed all the errors. Where possible I generally chose to use the raw_pc accessor, as it is less expensive. Note that this patch discounts the possibility that the text section offset might cause wraparound in the addresses in the line table. However, this was already discounted -- in particular, objfile_relocate1 did not re-sort the table in this scenario. (There was a bug open about this, but as far as I can tell this has never happened, it's not even clear what inspired that bug.) Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-08Remove OBJF_REORDEREDTom Tromey1-29/+0
OBJF_REORDERED is set for nearly every object format. And, despite the ominous warnings here and there, it does not seem very expensive. This patch removes the flag entirely. Reviewed-By: Andrew Burgess <aburgess@redhat.com>
2023-02-19Remove allocate_block and allocate_global_blockTom Tromey1-1/+1
This removes allocate_block and allocate_global_block in favor of simply calling 'new'.
2023-02-19Fix memory leak in mdebugread.cTom Tromey1-10/+9
mdebugread.c allocates blocks on the heap. However, this is a memory leak if the corresponding objfile is ever destroyed. This patch changes this code to use allocate_block instead, fixing a FIXME from 2003. I don't know how to test this patch.
2023-02-19Remove ALL_BLOCK_SYMBOLSTom Tromey1-7/+2
This removes ALL_BLOCK_SYMBOLS in favor of foreach.
2023-02-08Do not pass section index to end_compunit_symtabTom Tromey1-3/+2
Right now, the section index passed to end_compunit_symtab is always SECT_OFF_TEXT. Remove this parameter and simply always use SECT_OFF_TEXT.
2023-02-08Set section indices when symbols are madeTom Tromey1-4/+14
Most places in gdb that create a new symbol will apply a section offset to the address. It seems to me that the choice of offset here is also an implicit choice of the section. This is particularly true if you examine fixup_section, which notes that it must be called before such offsets are applied -- meaning that if any such call has an effect, it's purely by accident. This patch cleans up this area by tracking the section index and applying it to a symbol when the address is set. This is done for nearly every case -- the remaining cases will be handled in later patches.
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
2022-10-28Convert compunit_language to a methodTom Tromey1-1/+1
This changes compunit_language to be a method on compunit_symtab. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-09-21gdb: remove TYPE_LENGTHSimon Marchi1-3/+3
Remove the macro, replace all uses with calls to type::length. Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
2022-09-21gdb: add type::length / type::set_lengthSimon Marchi1-2/+2
Add the `length` and `set_length` methods on `struct type`, in order to remove the `TYPE_LENGTH` macro. In this patch, the macro is changed to use the getter, so all the call sites of the macro that are used as a setter are changed to use the setter method directly. The next patch will remove the macro completely. Change-Id: Id1090244f15c9856969b9be5006aefe8d8897ca4
2022-09-21gdb: remove TYPE_TARGET_TYPESimon Marchi1-2/+2
Remove the macro, replace all uses by calls to type::target_type. Change-Id: Ie51d3e1e22f94130176d6abd723255282bb6d1ed
2022-08-03Use gdb_bfd_ref_ptr in objfileTom Tromey1-3/+3
This changes struct objfile to use a gdb_bfd_ref_ptr. In addition to removing some manual memory management, this fixes a use-after-free that was introduced by the registry rewrite series. The issue there was that, in some cases, registry shutdown could refer to memory that had already been freed. This help fix the bug by delaying the destruction of the BFD reference (and thus the per-bfd object) until after the registry has been shut down.
2022-07-28Rewrite registry.hTom Tromey1-2/+2
This rewrites registry.h, removing all the macros and replacing it with relatively ordinary template classes. The result is less code than the previous setup. It replaces large macros with a relatively straightforward C++ class, and now manages its own cleanup. The existing type-safe "key" class is replaced with the equivalent template class. This approach ended up requiring relatively few changes to the users of the registry code in gdb -- code using the key system just required a small change to the key's declaration. All existing users of the old C-like API are now converted to use the type-safe API. This mostly involved changing explicit deletion functions to be an operator() in a deleter class. The old "save/free" two-phase process is removed, and replaced with a single "free" phase. No existing code used both phases. The old "free" callbacks took a parameter for the enclosing container object. However, this wasn't truly needed and is removed here as well.
2022-06-02ODR warnings for struct symlocTom Tromey1-5/+5
"struct symloc" is defined in multiple spots in gdb, causing ODR warnings. This patch renames these. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
2022-04-27gdb: remove BLOCKVECTOR_BLOCK and BLOCKVECTOR_NBLOCKS macrosSimon Marchi1-47/+37
Replace with calls to blockvector::blocks, and the appropriate method call on the returned array_view. Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd