| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
... instead of open-coding it. This also fixes two array underrun
issues, when plain char is a signed type.
|
|
... instead of open-coding it. Also convert a variable to plain char
(allowing to drop two casts), which is how it's actually used.
|
|
... instead of open-coding it. Also convert a variable to plain char
(allowing to drop two casts), which is how it's actually used.
|
|
... instead of open-coding it.
|
|
... instead of open-coding it.
In tic54x_stringer() this also fixes an array overrun issue: Converting
plain char to unsigned int could have yielded huge values when plain
char is a signed type.
In subsym_substitute() also convert a local variable to plain char, as
that's what it's really holding (and how it's used everywhere else).
|
|
... instead of open-coding it.
|
|
... instead of open-coding it.
|
|
... instead of open-coding it. This also fixes two array underrun
issues, when plain char is a signed type.
|
|
... instead of open-coding it.
|
|
... instead of open-coding it.
|
|
... instead of open-coding it.
|
|
... instead of open-coding it.
|
|
... instead of open-coding it.
|
|
... instead of open-coding it.
|
|
... instead of open-coding it.
|
|
... instead of open-coding it.
|
|
... instead of open-coding it.
|
|
... instead of open-coding it. With this there's no need for op_end (and
hence op_start) to be other than pointer to plain char. Which in turn
eliminates the need for several questionable casts.
|
|
... instead of open-coding it.
|
|
... instead of open-coding it.
|
|
... instead of open-coding it.
|
|
... instead of open-coding it.
|
|
... instead of open-coding it.
|
|
Fix use of is_end_of_line[] directly instead of through the
is_end_of_stmt() macro.
|
|
... instead of open-coding it.
|
|
... instead of open-coding it. This also fixes an array underrun issue:
The wrong casting to plain int could have yielded negative values when
plain char is a signed type.
|
|
... instead of open-coding it. Note that writes to the array need to be
left alone; they can only be converted when the array is folded into
lex_type[].
|
|
... instead of open-coding it.
|
|
... instead of open-coding it.
|
|
... instead of open-coding it. Convert a variable's type to plain char
then as well, as that's what it's really holding (and how it's used
everywhere else).
|
|
1. Remove gmon.out first before generating it in the configure check.
2. Make tst-gmon-gprof.out depend on the gprof binary.
3. Check that gmon.out is non-empty.
4. Don't include <sys/cdefs.h> in tst-gmon.c.
PR gprof/32764
* configure.ac: Remove gmon.out first.
* configure: Regenerated.
* testsuite/Makefile.am (tst-gmon-gprof.out): Depend on
$(GPROF).
* testsuite/Makefile.in: Regenerated.
* testsuite/tst-gmon-gprof.sh: Check that gmon.out is non-empty.
* testsuite/tst-gmon.c: Don't include <sys/cdefs.h>.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
I got an request about the undefined behaviors, considering the following case,
$ cat test.c
void main ()
{
foo();
}
$ cat lib.h
void foo(void);
$ riscv64-unknown-linux-gnu-gcc test.c
riscv64-unknown-linux-gnu/bin/ld: /tmp/ccRO8fJl.o: in function `main':
test.c:(.text+0x8): undefined reference to `foo'
collect2: error: ld returned 1 exit status
$ riscv64-unknown-linux-gnu-gcc test.c -Wl,--unresolved-symbols=ignore-in-object-files
$ qemu-riscv64 a.out
Segmentation fault (core dumped)
Testing with x86 and aarch64, they won't get the segfault since they go plt
for the undefined foo symbol. So, after applying this patch, I can get the
following too,
$ qemu-riscv64 a.out
a.out: symbol lookup error: a.out: undefined symbol: foo
The change of this patch should only affect the call behavior, which refer
to an undefined (weak) symbol, when building an dynamic executable. I think
the pic/pie behavior won't be affected as usual.
|
|
Copy a simple gprof test from glibc to test the basic gprof functionality.
1. Tested natively on Linux/x86-64 and Linux/i686.
2. Tested for the x86_64-solaris cross target without cross-compiler.
3. Tested for the aarch64-linux-gnu cross target with cross-compiler.
PR gprof/32764
* Makefile.am (SUBDIRS): Add testsuite
* configure.ac (AC_CONFIG_FILES): Removed.
(AC_OUTPUT): Add Makefile testsuite/Makefile
po/Makefile.in:po/Make-in.
(AM_CONDITIONAL): Add NATIVE.
* Makefile.in: Regenerated.
* configure: Likewise.
* testsuite/Makefile.am: New file.
* testsuite/tst-gmon-gprof.sh: Likewise.
* testsuite/tst-gmon.c: Likewise.
* testsuite/Makefile.in: Generated.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
|
|
Delete the test. It doesn't make sense to check a linker hack for
a meaningless p_offset.
|
|
Fix typos:
...
mainenance ==> maintenance
epilgoue ==> epilogue
commnds ==> commands
readibility ==> readability
informations ==> information
throwed ==> threw
compiletime ==> compile time
namepace ==> namespace
reqired ==> required
explicity ==> explicitly
reqired ==> required
...
|
|
Fix typos:
...
gdb/python/py-framefilter.c:749: indention ==> indentation
gdb/python/py-framefilter.c:837: indention ==> indentation
gdb/python/py-lazy-string.c:35: sting ==> string
gdb/python/py-progspace.c:119: Retun ==> Return
gdb/python/py-progspace.c:139: Retun ==> Return
...
|
|
Fix typos:
...
gdb/python/lib/gdb/disassembler.py:84: dissables ==> disables
gdb/python/lib/gdb/command/xmethods.py:40: experession ==> expression
...
|
|
Fix typos:
...
gdb/guile/scm-lazy-string.c:41: sting ==> string
gdb/guile/lib/gdb/iterator.scm:65: satify ==> satisfy
...
|
|
Fix typos:
...
preprend -> prepend
wth -> with
Connnections -> Connections
...
|
|
Fix typos:
...
Dependant ==> Dependent
...
|
|
Fix typos:
...
atribute ==> attribute
...
|
|
Fix typos:
...
exising ==> existing
afer ==> after
...
|
|
Fix typos:
...
gdb/tui/tui.c:64: releated ==> related
gdb/tui/tui-io.c:50: releated ==> related
...
|
|
Fix typos:
...
gdb/cli/cli-utils.h:85: fuction ==> function
gdb/cli/cli-decode.c:2457: Ambigous ==> Ambiguous
...
|
|
Fix typos in gdbarch_components.py:
...
tranformations ==> transformations
charater ==> character
Noe -> Note
...
and regenerate gdb/gdbarch-gen.h.
|
|
With the hierarchical name patches to GNAT, ada_add_block_renamings
must now be updated as well -- the comment there about the supported
forms of DW_TAG_imported_declaration is no longer correct, and now
full names must sometimes be constructed during the lookup process.
|
|
In the near future, GNAT will start emitting DWARF names in a more
standard way -- specifically, the package structure will be indicated
by nested DW_TAG_module DIEs and a given entity will be nested in its
package and only have a simple name.
This patch changes gdb to understand this style of naming, while still
supporting the existing GNAT output.
A few special cases are needed. I've commented them.
The name-computing code for the full DWARF reader is very complicated
-- much too complicated, in my opinion. There are already several
bugs in bugzilla about this (search for "physname"... but there are
others as well), so I haven't filed any new ones.
When I started this project, I thought it would solve some memory
overuse issues we sometimes see from how the index-sharding code
interacts with the GNAT-specific post-pass. However, to my surprise,
the Ada code in gdb relies on some details of symbol naming, and so
I've had to add code here to synthesize "linkage" names in some cases.
This is unfortunate, but I think can eventually be fixed; I will file
a bug to track this issue.
|
|
Unfortunately, due to some details of how the Ada support in gdb
currently works, the DWARF reader will still have to synthesize some
"full name" entries after the cooked index has been constructed.
You can see one particular finding related to this in:
https://sourceware.org/bugzilla/show_bug.cgi?id=32142
This patch adds a new flag to cooked_index_entry::full_name to enable
the construction of these names.
I hope to redo this part of the Ada support eventually, so that this
code can be removed and the full-name entries simply not created.
|
|
handle_gnat_encoded_entry might create synthetic cooked index entries
for Ada packages. These aren't currently kept in m_entries, but it
seems to me that they should be, particularly because a forthcoming
GNAT will emit explicit DW_TAG_module for these names -- with this
change, the indexes will be roughly equivalent regardless of which
compiler was used.
|
